 METLSLIME
#1 posted by starbuck [94.193.240.185] on 2009/02/12 13:07:56
you magnificent bastard
 Wagh
#2 posted by ijed [216.241.20.2] on 2009/02/12 13:55:20
 Yay
#3 posted by Spirit [213.39.203.162] on 2009/02/12 13:55:46
Sorry I did not reply to your mail, totally forgot about it.
Great stuff! :)
Quick suggestion: If max_edicts were exceeded mention that cvar in the error message? Took me a moment to realise I had the control over it.
 Eh
#4 posted by Spirit [213.39.203.162] on 2009/02/12 13:57:19
I mean, something like "max_edicts is currently set to 1024, try setting it higher, eg. max_edicts 2048."
#5 posted by Willem [71.70.208.255] on 2009/02/12 14:05:21
Awesome news!
"model interpolation"
Is this an option? :)
 Good News !!
#6 posted by JPL [213.30.139.243] on 2009/02/12 14:13:53
I had the opportunity to test it on my latest huge map, and it is running like a charm ! Now I can polish my project and release it with FitzQuake as the prefered engine !!
Metlslime did again a fucking good job here: Congratulations !
 Cant Wait To See
#7 posted by RickyT23 [81.157.18.236] on 2009/02/12 14:23:52
Sickbase with decent lighting :)
 SDL?
#8 posted by Bad Sector [79.131.128.198] on 2009/02/12 14:27:38
Wasn't there a SDL port? Why not continue the development from the SDL version so those who don't use Windows be able to use FitzQuake?
Beyond that, the new release seems fine and finally it remembers my video option :-P
 Mtlslm....
#9 posted by the silent [79.23.57.186] on 2009/02/12 14:45:40
..I can't evn prnns yur name... I'm soo excited... Yu soo sxy...
 Hell Yes W00t
#10 posted by KareemK [84.36.187.146] on 2009/02/12 15:40:42
hope the changes make it to the sdl port. i think its networking is broken
 Willem
#11 posted by Vondur [89.175.96.234] on 2009/02/12 15:45:36
read included txt file, there's everything
#12 posted by Willem [71.70.208.255] on 2009/02/12 15:50:56
Vondur
I would but, as Bad Sector said, I'm waiting for the SDL port to be updated. There's no point in my downloading a Windows only release. :)
Nice work, metlslime! I can't wait to play with this stuff. Alpha will be cool.
 SDL Port
#13 posted by SleepwalkR [85.179.4.130] on 2009/02/12 17:34:33
I have to talk with metl about what his current plans are for merging the original source and my SDL version, but either way, there will either be a merge of the two projects or I will port his changes to the SDL version.
 Thats Brilliant!
#14 posted by RickyT23 [81.157.18.236] on 2009/02/12 17:38:52
If you do that then Mac users will be able to play WARPSPASM, nsoe, +others :)
 Hmm
#15 posted by nonentity [87.194.146.225] on 2009/02/12 17:39:49
Also *nix users...
 Great News
#16 posted by Orl [76.98.214.54] on 2009/02/12 18:33:37
Does this finally mean no more having to worry about keeping Quake's original engine limits now that Fitzquake can play maps that exceed them?
 Great Job,
#17 posted by Drew [98.124.8.98] on 2009/02/12 18:37:34
thank you very much. you are a wonderful man and I hope you have a long and healthy dick.
 Splendido.
#18 posted by Text_Fish [82.32.29.116] on 2009/02/12 20:16:00
I can't wait to replay all the huge maps I've been forced to run in horrible engines for years on end.
#19 posted by Trinca [89.181.77.190] on 2009/02/12 22:57:41
Just test it!
Very smooth and fast, nice work John I will play more with the client now for sure!
 Metlslime:
#20 posted by RickyT23 [82.20.37.149] on 2009/02/12 23:05:44
I love you.
This engine works really well with fog and skyboxes simultaneously. The first one eva :) Actually AGLQuake had it but not as good (s00ry AguirRe)...
 Re:SDL
#21 posted by metlslime [64.175.155.252] on 2009/02/12 23:13:19
Wasn't there a SDL port? Why not continue the development from the SDL version so those who don't use Windows be able to use FitzQuake?
Much of the work on this version was done before the SDL port existed; basically it seemed easier to finish this version first, then attempt a merge.
As for what happens next, I'll have to figure that out with SleepwalkR.
 To The Brave
#22 posted by MadFox [84.26.168.11] on 2009/02/12 23:23:05
& wonderfull engine that speaks Quakes to my winXP!
metl...you rock!
 Congratulations!
#23 posted by generic [67.233.217.4] on 2009/02/13 00:46:34
The Rubicon 2 test map was not included in the ZIP file though ;-)
 It's Like Christmas And Birthday Together
#24 posted by rudl [85.126.193.66] on 2009/02/13 01:44:38
I won't replay warpspasm now, already played it twice, but I hope that we will see a lot of huge, massive epic sp episodes.
 Just Want To Re-itterate Post #20
#25 posted by RickyT23 [82.20.37.149] on 2009/02/13 03:46:22
Seriously though this is a big thing! It annoyed me that if you put a little fog on you couldnt see the skybox at all in every single engine. But I had a look at thehand before and it seemed to be working fine!
 Metl
#26 posted by than [221.244.26.90] on 2009/02/13 06:11:40
I love you.
 Some Maps Worth A Second Look Now ...
#27 posted by Baker [75.118.7.231] on 2009/02/13 06:48:56
Forwards Compatible ...
http://www.celephais.net/board/vie...
This might have secretly been one of the best releases in 2008: a lot of alpha brushes, Enforcer reskinned grunts and Hell Knights, SNG wielding mega-enforcer for a nice base theme with traditional play. Was not enjoyable in FitzQuake 0.80 due to the lack of alpha support.
Laboratory X
http://www.celephais.net/board/vie...
Some very large areas. Some very different looking textures. Couldn't previously run in FitzQuake.
 Loads All Known Limit Breaking Maps?
#28 posted by quakis [81.76.42.128] on 2009/02/13 09:57:28
Sounds good to me! Nice work.
 -quoth
#29 posted by necros [99.227.108.217] on 2009/02/13 20:08:00
thanks for adding support for that command line. :) now i can keep all my files in their own pak0.pak in a completely seperate folder and not have to muddy up the quoth folder anymore.
#30 posted by Ankh [88.199.103.6] on 2009/02/13 22:26:26
Great work metlslime.
Thanks for the v_gunkick variable and model interpolation.
I have found one small bug. The variable - scr_crosshairscale isn't working because the client has it coded as "- scr_crosshaircale" (the "s" is missing I mean)
 Ankh--
#31 posted by metlslime [64.175.155.252] on 2009/02/13 22:48:42
I have found one small bug. The variable - scr_crosshairscale isn't working because the client has it coded as "- scr_crosshaircale" (the "s" is missing I mean)
aw, damnnit :P
 Woohoo
#32 posted by Mr Fribbles [121.44.197.180] on 2009/02/13 23:24:37
This is more exciting than almost any new game release! Some great changes listed, thank you for your continual work on this, metl.
As for this...
Does this finally mean no more having to worry about keeping Quake's original engine limits now that Fitzquake can play maps that exceed them?
Yes, but I look forward to watching with amusement as people complain that they're hitting the new limits in 1-2 months...
 Is The Model Interpolation Code
#33 posted by nitin [124.168.13.132] on 2009/02/14 02:34:33
different to that used in other engines? It seems to be a bit more jerky and/or delayed than something like aglquake. Using r_lerpmodels 1 and r_lerpmove 1.
 /me
#34 posted by than [219.75.209.249] on 2009/02/14 02:48:20
disables r_lerpmodels and r_lerpmove
It's too weird when Quake's awesome jerky animation is suddenly all smooth :)
Still, nice release. I think the engine limits stuff is the most important this time round.
p.s. I still love you, Metl
 Nitin:
#35 posted by metlslime [64.175.155.252] on 2009/02/14 03:50:51
yes, it's different. I looked at the tutorial code found on QER, which i think is where most people get their code, but wrote my own based on what i learned there.
Can you tell me what seems jerky? With r_lerpmodels 1, some specific things aren't interpolated, such as the firing frames of weapons and monsters, and all frames of various torch models. If you want to enable interpolation all the time for everything, try r_lerpmodels 2.
 Lerpmodels 2
#36 posted by nitin [124.168.13.132] on 2009/02/14 06:02:06
that was it. I was used to seeing everything interpolated so when I saw it in lerpmodels 1, I could notice the difference when certain frames were not interpolated (especially when monsters fired).
thanks.
 Holy Cow!
#37 posted by dooomer [60.180.151.113] on 2009/02/14 07:55:02
This one was long awaited for sure! I will try to run Warpspasm on this! Thanks for your hard work!
 Warpspasm Looks Funny Without Interpolation
#38 posted by onetruepurple [79.191.247.18] on 2009/02/15 00:25:07
Thanks for the release.
 Angling
#39 posted by Preach [217.44.219.227] on 2009/02/15 03:11:22
metl, did you sneakily add double precision angles into your new protocol? Because I swear I can feel the difference...
 Heh
#40 posted by necros [99.227.108.217] on 2009/02/15 04:30:36
i just checked, and there is a big difference between 080 and 085! :D
 Preach:
#41 posted by metlslime [166.191.140.152] on 2009/02/15 08:11:41
Yeah, the new protocol has two-byte angles for client aiming (implied by the "Improved crosshair accuracy" feature) :)
 ?
#42 posted by necros [99.227.108.217] on 2009/02/15 10:47:58
am i imagining it or are all the rotating objects smoother now?
 Fitz 85 Is Worth A Look...
#43 posted by robot [209.29.44.76] on 2009/02/15 16:47:56
Monsters move prefectly smooth now on my Radeon 9000 Pro and Fitz 85.
Couldn't get it with Fitz 80 (really choppy movement at first, then
slowly gets better around the middle of the game). Previously only
Aguirre's GL ran pefectly for me. Now I got all those nice .lit maps
to try out, and still, the best looking animated sky !
 Demo Compatibility
#44 posted by gb [89.27.247.2] on 2009/02/15 19:48:41
Which other engines can play back Fitz 0.85/protocol 666 demos?
 Gb:
#45 posted by metlslime [166.134.195.77] on 2009/02/16 04:04:34
None right now. I plan to look at aguirre's convdem tool to see if I could add support for this new protocol, otherwise I may write my own.
 Congrats Metl !
#46 posted by spy [92.47.187.108] on 2009/02/16 15:53:49
great job!, yeah, there is a big difference between 080 and 085 as said previously :)
 Wasted Some Hours
#47 posted by Mechtech [71.70.253.13] on 2009/02/18 00:51:58
 WarpB
#48 posted by yhe1 [71.110.178.172] on 2009/02/19 22:40:01
This does not open Warpb?
 Does
#49 posted by onetruepurple [79.191.243.19] on 2009/02/19 22:53:38
Are you sure you're running Warp with increased heapsize and/or edicts?
#50 posted by yhe1 [71.110.178.172] on 2009/02/19 23:14:33
How do I increase edicts? I am running with Heapsize 120000
 Yhe1:
#51 posted by metlslime [64.175.155.252] on 2009/02/20 04:16:46
in the console, type "max_edicts 2000" or similar. (default is 1024.)
 Metlslime:
#52 posted by bear [94.255.217.159] on 2009/02/23 00:54:08
What's the technical solution used for "gl_flashblend 0" effects? Firing rockets with that setting is a real fps killer on my hardcore intel integrated graphics :( (apart from that FQ runs very well)
 Bear:
#53 posted by metlslime [24.130.223.174] on 2009/02/23 06:30:15
the app keeps local copies of all lightmaps; when dynamic lights touch a surface, the dynamic light is added to the static light levels and the new data is uploaded to the texture using glTexSubImage2D.
Does fitzquake 0.85 actually run slower than earlier fitzquakes, or any other glquake ports with the same setting?
 Seems To Be For Fitzquake >065
#54 posted by bear [94.255.219.165] on 2009/02/23 11:52:47
vanilla Glquake also runs fine so I guess it has to be related to some of the changes you've made.
I'm mostly interested in figuring out the limits of the graphics card (GMA4500mhd) to avoid running into problems with projects of my own. It seems the intel drivers are lagging far behind in OpenGL support compared to DirectX and so far the lesson seems to be to stay away from OpenGL if you want to be safe :|
 Hmmm....
#55 posted by metlslime [24.130.223.174] on 2009/02/23 13:02:01
well, adding colored light capability in 0.75 probably increased the total amount of upload data somewhat (3 bytes per sample instead of 1) but if you also have the problem in 0.70 i'm not sure what it could be.
 Intel
#56 posted by yhe1 [71.110.178.172] on 2009/02/23 20:43:54
Fitzquake 0.80 had graphics problems on my Intel G945 card, but not 0.85. Aguirre's nehquake works fine also.
 Yhe1:
#57 posted by metlslime [64.175.155.252] on 2009/02/23 22:19:32
there are a couple of intel-specific fixes in the latest build, for example the "loading" icon isn't drawn because intel doesn't like rendering to the front buffer. Plus, some sort of alt-tab fix. Glad it all works!
 Hmm That's Pretty Weird
#58 posted by bear [94.255.221.140] on 2009/02/24 23:51:56
If nothing related was changed between those versions.
 Bear:
#59 posted by metlslime [64.175.155.252] on 2009/02/25 00:44:18
well, in my 0.70 changelist it does say "dynamic lighting has been moderately sped up." So maybe I actually did something to make it slower, instead, at least on some cards.
 Hmm Yeah
#60 posted by bear [94.255.221.140] on 2009/02/25 01:07:12
and not just slower but awfully slow in this case.. one nice thing I learned by testing all the different fitzquakes was that generally FPS has been improved a lot and in 0.85 and seems to be in the 100-200+ range as long as there's no dynamic lighting but fire a rocket and it can drop as far as into the single digit realm.
#61 posted by yhe1 [71.110.178.172] on 2009/02/25 06:44:52
One thing that has bothered me for a while is that While playing Quake with Fitzquake/Aquirre Quake is that you sometimes get lower framrates when there a lot of of light flickering/torches, such as at the beginning of Nightjourney and Five Rivers Land, or Event Horizon. I know that r_flatlightstyles can be used to fix this, but then the flicker lights are gone also. However, If I use an Old version of Darkplaces, such as DPnehahra, DP1.05, or DP1.02, I can get good framerates as well as keep the dynamic light. Does anyone know why DP can do this and Fitzquake/Aguirre Quake cannot?
 Yhe1:
#62 posted by metlslime [24.130.223.174] on 2009/02/25 07:15:44
i'm not really sure; in general, fitzquake and aguirre quake are much closer to the original glquake in terms of lighting code, and darkplaces is much more modified. As to why old darkplaces does it well and new darkplaces doesn't, that i also don't know.
How does glquake itself compare? And what about older versions of fitzquake?
 Metlslime
#63 posted by JPL [213.30.139.243] on 2009/02/25 08:12:03
To be honest with you, I never noticed such frame rate drop down with my maps (i.e Five Rivers Land / Event Horizon), whatever the engine I used in between aguirRe's GLQuake, and your engine...
Maybe it depends also of the CPU speed ... though..
#64 posted by yhe1 [71.110.178.172] on 2009/02/25 08:53:35
Metlslime:
I used to think that it was the flickering lights itself lead to the framerate drop, but then like I said, old DPs do not have this problem.
For the record, the Old DP did not have problems generating the Doors to Ricky's map either.
I don't have the original GLquake, but Fitzquake 0.80 also had the framerate drop, as did Agirre nehquake and nehwarp
JPL:
I believe the framerate problems were reflected in the FRL and the EH threads by multiple people. I used the old DP to run your maps because I think that dynamic lights adds to the atomsphere of a base map. Hopefully you won't place too many enemies alongside flickering lights in your next map because I know that it is going to break the limit of the old DP.
 5river
#65 posted by rudl [78.104.15.36] on 2009/02/25 10:54:04
I did notice it even on a fast computer. Try to add
-nomtex to the command line, that helped.
 Intel GMA (integrated Media)
#66 posted by Baker [75.118.7.231] on 2009/02/25 11:48:30
http://en.wikipedia.org/wiki/Intel...
The problems bear and yhe are having with Intel GMA cards are not related to the "computer" or the "cpu".
These Intel GMA cards are default 3d accelerator ("onboard intergrated video card") on all machines with a Intel processor (even Intel Mac Minis).
If you have an Intel processor and didn't buy a graphics card, this is what you have (2001 and later). This is most computers .. well not most .. the overwhelming majority.
Their performance is "fair", about 120-250 frames per second with standard GLQuake with the default settings (gl_flashblend 1, etc.).
It is very nice that metlslime added in the "Intel display adapter fixes" to make it so a lot more people can use FitzQuake.
But keep in mind, the performance of these is on the lower end of the spectrum.
If aguirRe's GLQuake has the framerate drop too -- consider that the lighting in that engine is original GLQuake (no lit support, etc.) and original GLQuake is 1997.
The Intel GMA series is nice in the sense that virtually all computers can be expected to be able to play games, but it is still on the low end of graphics performance.
They have OpenGL 1.2 compatibility with some drivers having portions of the OpenGL 1.3/1.4 specification.
/Note: in old DarkPlaces there are some comments by LordHavoc stating "major lighting speedup" in the dynamic lights section.
 Intel Opengl Compat
#67 posted by bear [94.255.221.140] on 2009/02/25 13:31:18
The higher end GMA:s (including mine) have OpenGL 2.0 support with the latest drivers and if intel felt like implementing more than that it should be possible considering what the card supports in DirectX.
 On Intel Topic Pherhaps But Not Really FQ
#68 posted by bear [94.255.221.140] on 2009/02/25 14:24:26
Found this Direct3D quake port which seems to run really great: http://sourceforge.net/projects/di...
 Bear
#69 posted by Spirit [213.39.174.81] on 2009/02/25 15:55:32
Give MH's new engine a try, it's DirectX 9 or 10 and definitely better than that old one: http://forums.inside3d.com/viewtop...
 Spirit:
#70 posted by bear [94.255.213.180] on 2009/02/25 18:10:00
Well maybe you should have checked the link because "that old one" seems to be the same one you suggest!
 Yhe1:
#71 posted by metlslime [64.175.155.252] on 2009/02/25 23:44:17
It sounds like all glquake ports will give you the same problem, with the exception of engines that specifically improved things.
I'll check out darkplaces again and see what I can learn from it.
Can you tell me if the version of darkplaces that runs fast also supports .lit files?
#72 posted by yhe1 [71.110.178.172] on 2009/02/25 23:49:52
Yes, the old DPs also supports lit files
 DP Version
#73 posted by Baker [75.118.7.231] on 2009/02/26 01:52:50
I downloaded several DP sources to identify the first version with the dynamic lighting speedup, DarkPlaces 0.72 appears to be the first occurrence.
http://icculus.org/twilight/darkpl...
The important changes appear to be in gl_rsurf.c and r_light.c (R_DynamicLightPoint, R_DynamicLightPointNoMask, RecursiveLightPoint, ...)
 Dear Bear
#74 posted by Spirit [80.171.29.2] on 2009/02/26 10:48:01
 #64
#75 posted by JPL [213.30.139.243] on 2009/02/26 11:00:41
Hopefully you won't place too many enemies alongside flickering lights in your next map because I know that it is going to break the limit of the old DP.
Yhe1: Unfortunately, I do not test my maps with DarkPlace. I am using metlslime FitzQuake (0.85 now) as reference engine, and I think it is largely enough... So I cannot ensure that you will not face issues with old DP version... sorry for this ;)
 JPL
#76 posted by negke [85.176.85.175] on 2009/02/26 17:15:39
That's poor mapping style. Giving the map a quick run-through in the most common engines is not too much to ask.
 Negke
#77 posted by JPL [82.234.167.238] on 2009/02/26 18:22:57
I installed DP once, a while ago, and for some dark reasons it crashes after some minutes... so I decided to stick to more than most common engine... FitzQuake is the reference here, so it is largely enough for me if my maps run properly on it...
And I don't think it is a poor mapping style: it is rather a poor testing style :P
 Had This Slowdown On Fitz Too (0.80)
#78 posted by rudl [85.126.193.66] on 2009/02/26 18:28:16
 Agree With JPL
#79 posted by HeadThump [4.136.90.35] on 2009/02/26 18:52:43
DarkPlaces doesn't mix well with ATI. It's ATI's fault for a long history of shitty Opengl support, but that doesn't change the fact that when Dark Places crashes it REALLY crashes. I lost my firewall registration information the last time my computer crashed after installing the latest ATI drivers and running Dark Places and it was a big hassle to get everything back in order on that front, so I will never take that risk again.
 Common Engines
#80 posted by Preach [81.153.29.95] on 2009/02/26 19:43:30
Testing in common engines is one thing, but darkplaces compatibility shouldn't be expected. DP is from my experience just too far removed from a regular quake engine for people to negotiate around it. It's like where you have horses and donkeys: they can interbreed, but the offspring is sterile. Usually things fall into two categories, made only for DP, and made for other engines. If the latter work in DP, then great, but often it's too much work or sacrifice to achieve.
#81 posted by yhe1 [140.144.202.70] on 2009/02/26 19:49:46
@JPL:
Does the old DPs still crash for you, like DP1.02?
And your new map, is it going to be limit breaking (the Fitzquake 0.80 limit)?
 Negke
#82 posted by yhe1 [140.144.202.70] on 2009/02/26 19:52:27
Ironically, one of your Travail secret maps also had the same Framerate problems as Five Rivers Land ;)
 Yhe1
#83 posted by JPL [82.234.167.238] on 2009/02/26 20:01:37
I don't remember which version it was.... so I can't tell you. Also, I deleted DP from my HD, just playing with aguirRe's GLQuake, and FitzQuake..
Fortunately, it was not as dramatic as HeadThump mentionned: I didn't had to re-install everything on my computer...
#84 posted by Spirit [80.171.29.2] on 2009/02/26 20:14:35
The think with Darkplaces is that many people use it (because it looks SO AWSUM!). If you want your stuff to be played by newbies then you should test it.
 Donkeys And Horses
#85 posted by Preach [81.153.29.95] on 2009/02/26 22:18:20
Lemme give you my canonical bugbear. When regular engines report the size of a sprite "model" in the QC fields mins and max, they set them to the dimensions of the sprite in pixels, relative to the origin of the sprite. Since quake renders at 1 unit to 1 pixel, this is a very useful feature, and Quoth uses this information to create a solid bounding box around wire-mesh/grill entities.
Darkplaces sets these fields differently. It reports roughly sqrt(2) times the largest dimension in each coordinate, effectively giving a bounding box for the sprite at any rotation. I didn't actually know it did this until someone reported that the quoth basetest wasn't completable. As a result of the difference, the solid bounding box generated by each mesh is much larger, blocking off the hole next to the mesh through which you must climb.
The thing is, there isn't much that can be done about this particular difference in engines, besides throw out the "solid" feature or make it much more effort to use (by requiring mappers to manually enter the dimension of the sprite on the entities). So even if I had known ahead of time, I probably would have said it was something for DP to fix. Perhaps it's a bit different when it comes to making maps compatible, but that's my take on the matter.
 Preach:
#86 posted by metlslime [64.175.155.252] on 2009/02/26 22:57:19
probably best to let mappers place clip brushes. That's how I did it back when I had sprite-based grates in rubicon2. I decided to stop using them because:
1. they don't take the ambient or dynamic lighting at all (I actually had 6 frames which were the same grate but different light levels.)
2. on almost all non-fitzquake engines, they have ugly pink edges.
 Yeah
#87 posted by Preach [81.153.29.95] on 2009/02/27 00:47:32
The solid box is optional, you can also use clipping brushes. It's whether you want to allow projectiles to pass through or not. It seemed a shame to require an extra entity to be the invisible hull if you want to block shots as well as players. As for the orange edges, people can usually see past them, if you go for rusty textures at least.
 Preach:
#88 posted by metlslime [64.175.155.252] on 2009/02/27 02:02:27
true, the pink edges are fairly subtle when the artwork itself is warm orange/red in color, such as the light globe sprite in original quake.
As for blocking bullets/projectiles, this can also be accomplished with a skip brush instead of a clip brush. Except the skip brush will cast a shadow, unless you make it a func_wall, which as you say, is an extra entity.
Unless! maybe you can assign a brush model to the sprite entity, which the quakec code uses to call setsize() and then changes the model to a sprite after that. Of course this uses a model precache :P
#89 posted by MadFox [84.26.168.11] on 2009/02/27 03:07:05
The burning can I made with the zdoom model had the same strange line along the sprite.
It seemed as if the used pictures needed an extra line surrounding them. And to stay within the 4 divided measure for gl they became bigger.
Without line.
 Darkplaces
#90 posted by gb [89.27.246.111] on 2009/02/27 04:40:00
The think with Darkplaces is that many people use it (because it looks SO AWSUM!). If you want your stuff to be played by newbies then you should test it.
Careful here.
It has a couple useful extensions (like nonsolid, but shootable corpses), it runs TWIG, and it supports CSQC, which allows you to do lots of otherwise impossible stuff like moving sound sources, inventory, keyboard input - ever tried to getchar() in qc? and more things like that.
Yes, the newbie/awsum effect is there, but careful plz, modders don't prefer it for nothing.
DP/FTE/QSG extensions and csqc have been the answer to a surprising amount of questions I came up with during RMQ development, and by now I think Darkplaces is rather awesome.
I used to think like you, though. ;-)
I would like to see CSQC supported by Fitzquake type engines, please. Because quite frankly, it is awesome.
 Down On Darkplaces Is *bad*
#91 posted by Baker [75.118.7.231] on 2009/02/27 07:08:33
DarkPlaces is structured in a radically forward thinking way.
The memory management, the QuakeC handling, movie playing capability, the protocol, true interpolation (try setting max fps to 500 and watch what other engines do when you use a lift) and on and on.
Most engines don't even have simple basic fixes like not aborting when a model isn't found, a chase cam that doesn't poke through walls, colormapping of dead player bodies, view weapon capability and on and on.
Most new features engines have added in recent times are things that DarkPlaces has had for several years.
LordHavoc's work has been far, far ahead of the times even in the early days (DP has had color mapping of dead bodies since 2000).
 To Be Honest
#92 posted by JPL [82.234.167.238] on 2009/02/27 07:54:58
I don't think that because DP has a different behaviour and different features compared to "standard" engines (e.g FitzQuake... ) that it can be said that DP is "bad": it is just different.
Well, I don't want to drop down DP just because it crashes my PC once, and I'm pretty sure I can find many people that think DP is better than FitzQuake, just because there are used with it
 Gb
#93 posted by Spirit [213.39.225.91] on 2009/02/27 08:49:38
I think you think to know my thoughts while you don't. :p
Darkplaces is an amazing engine in my opinion. Sadly it breaks Quake "compatibility" a bit too much. So I don't think it is that good to play Quake singleplayer maps/mods.
What I said up there should be read as: Many newbies go for Darkplaces just because it has realtime lighting, parallax(?) mapping, shiny water and maybe the soundtrack support. They don't give a fuck about the "developer features". But then they mostly don't play custom maps either I guess, so ...
 I Love You!
#94 posted by Gunter [4.159.56.106] on 2009/02/27 08:52:56
I have been waiting for SO long for someone to create a quake client that properly interpolates the monsters, yet doesn't stick in a ton of eyecandy....
Darkplaces was nice and had correct interpolation, but changed too much stuff and had too much eyecandy and the exe size got too big.
Every other client used the same copy&paste interpolation from some tutorial that would not correctly smooth the monsters' movement when connecting to a remote server.... They would still be all jerky.
But this new fitzquake does it right! The monsters on FvF look great now that they aren't hopping around like they are spastic!
Finally a GOOD ProQuake replacement....
Great Work!
http://www.fvfonline.com
connect FvF.ServeQuake.com
 Feature Request
#95 posted by Gunter [4.159.56.106] on 2009/02/27 08:59:57
How about adding in ProQuake remote console functionality for remote administration of servers (RCON)?
I could really, really use that.... It makes things so easy.
 Gunter:
#96 posted by metlslime [64.175.155.252] on 2009/02/27 23:36:53
do you mean, adding support so a fitzquake client can RCON to a proquake server?
 RCON
#97 posted by Gunter [4.159.56.216] on 2009/02/27 23:57:10
Yes, or some other way to remotely control a server. ProQuake's RCON works well and is easy to use. And since ProQuake already contains this functionality, it seems like it would be easiest to just copy the ProQuake stuff. Then FitzQuake would be able to RCON to a ProQuake server or to a FitzQuake server.
Another nice ProQuake feature that would be easy to add is the longer text chat lines....
I'm going to compose an e-mail with more feedback/bug reports/suggestions.
 Late To The Party, As Always
#98 posted by lth [94.193.174.213] on 2009/03/02 00:15:46
Christ, if someone's naming Forwards Compatible as "secretly one of the best releases of 2008" then the rest of y'all should be ashamed of yourselves.
 Metlslime:
#99 posted by yhe1 [140.144.202.70] on 2009/03/03 04:43:43
I was wondering if you looked into LordHavoc's dynaimc lights speed up option and the possibility of putting it in Fitzquake? Thx
 Yhe:
#100 posted by metlslime [64.175.155.252] on 2009/03/03 04:58:01
I haven't really looked into it yet, but based on baker's post, it sounds like that was merely a speedup to the code for determining the floor light value under a monster (since that is how monsters and players are lit, based on what they're standing on.)
Second, i already probably use that optimization, since i got my .lit support code from darkplaces, and that includes the changes to R_LightPoint and related functions.
The major issue with glquake lighting in general is that it requires uploading new lightmap textures anytime the lightmaps change, which is one of the slowest things you can do with a video card. At some point I will look at ways that can be improved; I can think of a bunch off the top of my head (using 8bpp textures when level has no colored light, uploading more, smaller rectangles of texture data instead of fewer, larger ones, etc.)
 One More Question
#101 posted by yhe1 [71.110.178.172] on 2009/03/04 08:25:27
What is the proper command line to run nehahra with Fitzquake 0.85?
 Yhe1:
#102 posted by metlslime [24.130.223.174] on 2009/03/04 08:48:28
no Nehahra support (...yet)
 Haha, "for Some Reason"
#103 posted by Mr Fribbles [118.208.155.135] on 2009/03/05 14:52:48
I installed DP once, a while ago, and for some dark reasons it crashes after some minutes...
You're using DP.
 For Some (very Good) Reasons
#104 posted by JPL [82.234.167.238] on 2009/03/05 15:21:46
... I'm not using it anymore :P
 This Engine
#105 posted by ijed [190.20.116.11] on 2009/03/07 17:02:29
Is the business.
 Another Question...
#106 posted by yhe1 [71.110.178.172] on 2009/03/11 02:36:23
Can somebody explain what the -nomtex command line option does?
 Yhe1:
#107 posted by metlslime [24.130.223.174] on 2009/03/11 08:10:59
That disables multitexture rendering.
#108 posted by yhe1 [71.110.178.172] on 2009/03/12 05:04:11
Can you explain a little bit more in depth? I was wondering how disabling the multitexture rendering helped the dynamic light speed up issue.
 Yeah...
#109 posted by metlslime [24.130.223.174] on 2009/03/12 08:38:31
In Fitzquake, (and glquake with gl_texsort 1) polygons are sorted by texture and then all the polygons for each texture are rendered, then all polygons for the next texture, and so on.
With multitexture enabled, the lightmaps are rendered at the same time, and when a lightmap needs to be updated for dynamic lighting, it triggers an upload.
Without multitexture, the lightmaps are rendered in a second stage after all textures. And, during this second stage, the polygons are sorted by which lightmap they use. And there might be a difference in how the uploads are done, since the lightmaps are encountered in a different order.
Since switching textures while rendering is somewhat expensive, but uploading textures is more expensive, but the total amount of lightmap uploads vs. the actual total number of lightmap pixels uploaded might have different costs, either one could be faster on different maps, different video cards, etc.
One of the things on my to-do list is a general optimization and rendering overhaul, so i might be able to get this stuff sped up even more.
 Water Too Foggy.
#110 posted by Paradise [74.72.244.115] on 2009/03/12 18:51:16
Very happy with this other than water is very foggy and hard to see in it. What inputs make it clear? Otherwise it is deff. keeper! :P
 It Does Seem Foggier
#111 posted by Gunter [4.159.177.32] on 2009/03/12 23:53:55
And I think the Ring of Shadows fog is too foggy as well.... and when you're wearing a ring AND are underwater, it's way-too-super-foggy!
I don't want the fog effects turned off completely though....
(metlslime, did you get that e-mail I sent?)
 Gunter:
#112 posted by metlslime [64.175.155.252] on 2009/03/13 02:49:29
sorry, haven't had a chance to respond to your email yet, but i did recieve it.
About the screen coloring for water and powerups, i haven't changed this from GLQuake as far as i can remember, so i'll have to check again and see what's up with that.
#113 posted by Spirit [80.171.28.95] on 2009/04/05 21:23:30
There seems to be some issue with ATI.
Some german guy reported this:
http://r4d1um.seitzinger.eu/DSC000...
Ati Radeon X1250 with latest drivers
AMD Turion 64 X2 TL-60 2x2,0 GHz & 2 GB Ram
Windows XP SP2 (32 Bit)
If he starts the game it looks like that. If he alt-tabs out and right back in it fixes itself. But as soon as the next map is loaded it is garbled again and he has to alt-tab out and in once more.
He encounters the same in GL Quake, GL QuakeWorld and Hexen II.
 I Have Similar On My X1300
#114 posted by RickyT23 [81.110.17.73] on 2009/04/05 21:35:28
at work (shhh) ;)
 Spirit:
#115 posted by metlslime [24.130.223.174] on 2009/04/06 01:15:03
any idea, does he have this issue with all glquake engines or do some have fixed behavior?
#116 posted by Spirit [80.171.28.95] on 2009/04/06 10:19:31
Dunno, I could ask him to try some. Which ones would be good? aguirRe's and Joequake maybe?
 -bpp 32
#117 posted by HackNeyed [74.137.64.232] on 2009/04/06 18:34:00
I have the same problems on ATI hardware. The fix? Add -bpp 32 to the command line or in the case of Fitzquake it can be set in the config.
 Great
#118 posted by Spirit [213.39.225.207] on 2009/04/06 22:07:04
That fixed it for that guy too. Thanks!
Maybe make 32 bit the default in the future?
#119 posted by yhe1 [140.144.202.70] on 2009/04/07 01:25:04
Doesn't it run slower then?
#120 posted by Willem [24.163.61.78] on 2009/04/07 01:30:18
These days? I can't imagine.
 Not Slower...
#121 posted by metlslime [64.175.155.252] on 2009/04/07 01:35:37
but it uses more memory (since quake loads all textures are at the same color depth as the framebuffer.) So 32bpp uses twice the total video memory compared to 16bpp.
 Oh And...
#122 posted by HackNeyed [74.137.64.232] on 2009/04/07 07:12:30
I forgot to add as it might be a clue for someone as to what is happening. When I adjust my laptop's volume there is an on screen over lay to indicate the volume change and that will also fix the screen corruption... That is, until I enter the menu, then I can enter and leave without issue but moving the menu selection will often corrupt again and always when I change level/demo.
I think my nvidia machine had the problem as well but is has been out of order for a while and I really cant remember, it has a GTX 280 so when it was working I was playing CoD4 and L4D and Unreal3 a bit more then Quake.
 Yep
#123 posted by than [221.244.26.90] on 2009/04/09 11:49:46
I had the same problem that was solved as soon as the japanese text input overlay appeared. Going in and out of the console (same key as to activate the overlay) fixed it all. Hardly ideal though, but I think it all works now, though I've not tried in a little while
 Transparent Water On Funcs
#124 posted by negke [88.70.53.7] on 2009/05/05 20:51:56
If the water volume touches a wall which is part of the same entity, it will be transparant, too, so you can see through the wall (think skip window trick).
 Yeah...
#125 posted by metlslime [173.11.92.50] on 2009/05/06 00:59:19
that's because quake bmodels don't support liquid contents, even though they support liquid textures. The inside of a water-textured func_door brush is considered solid by the compiler, so when solid touches solid the interior faces are removed.
 Ideas For The Future
#126 posted by Baker [75.118.7.231] on 2009/05/09 00:48:53
FitzQuake 0.85 is a pretty rock solid release.
Whenever you get the itch for 0.86 or 0.90 a couple of a nice and convenient fixes would be:
1) Record a demo at any time
2) Multiple core bug-fix which mostly relates to the clock code. Some of the dual/quad core machines can have some serious issues with the clock (DarkPlaces, Qrack, JoeQuake, every Quakeworld mod, ProQuake all have the fix).
3) Demo to AVI capability. Some of these better custom maps deserve a video (YouTube or otherwise) but because FitzQuake is really the only remaining engine (well, and aguirReQuake too) without dem to avi and because it is the single player map making community standard, it hasn't caught on here (not that most people know how to do it, but seeing it in the Quakeworld or modding community is somewhat common and believe me it isn't hard to do either from the make the video standpoint or even the add it to the engine standpoint -- I added it to aguirReQuake in 30 minutes last year [and then sent aguirRe the source in the event he was interested, but alas he's kinda moved on]).
 Regarding #2...
#127 posted by metlslime [173.11.92.50] on 2009/05/09 01:04:55
is this just the switch from a float to a double for the system time calls?
 Sys_Doubletime
#128 posted by Baker [75.118.7.231] on 2009/05/09 13:29:52
#2 is a Windows specific issue (Mac/Linux not affected)
To fix you are mostly changing sys_win.c for the clock initialization and the Sys_Doubletime calls.
It is rather straightforward, I added to ProQuake when someone reported the problem about a year and a half ago and did it in 3 hours or less without any advance planning.
I believe I had included the change in the modified FitzQuake 0.80 source I made last year.
Someone experiencing the problem will have very erratic speeds when playing a demo (too fast or too slow) and gameplay will be choppy and jerky.
 FitzQuake 0.85 SDL Prototype
#129 posted by Baker [75.118.7.231] on 2009/05/09 21:53:46
I have a prototype FitzQuake 0.85 SDL almost done [because without a FitzQuake 0.85 SDL I can't play the maps on my Mac I like in the context I want].
I posted this here [versus the FitzQuake SDL thread] mostly because I'm thinking about attempting to merge FitzQuake 0.85 and FitzQuake SDL into a single set of source code.
 Ha
#130 posted by Spirit [213.39.174.137] on 2009/05/09 22:05:06
(Sometimes) You rock!
I was bugging metl the other day when that merge would happen and expected it some time in 2010.
 You Know ...
#131 posted by Baker [75.118.7.231] on 2009/05/09 22:27:57
It's just a lot of busy work to do it really.
I'll let you do the compile on Linux ;)
 Baker:
#132 posted by metlslime [24.130.223.174] on 2009/05/10 00:54:18
that's pretty cool, i'm sure a lot of people will find it useful.
My fitzquake work is pretty much in stasis right now, as i'm trying to actually finish rubicon2, finally.
 Yay!
#133 posted by RickyT23 [86.0.125.18] on 2009/05/10 02:49:45
A Mac engine which supports limit breaking maps!?!??!! A benchmark has been hit!!! :)))
 Baker
#134 posted by SleepwalkR [85.179.25.31] on 2009/05/10 11:08:33
That sounds awesome! I was going to try and merge the two myself, but now it looks like I don't have to. i can help out with the OS X launcher if you like. Or you can just copy it from my old SDL sources.
#135 posted by Willem [24.163.61.78] on 2009/05/10 11:14:40
I have a prototype FitzQuake 0.85 SDL almost done [because without a FitzQuake 0.85 SDL I can't play the maps on my Mac I like in the context I want].
Do you need someone to carry your first born, Baker? You would be my personal Jesus if you get this done. I too play on Mac and would LOVE to get some of these new features and limits!
 And ...
#136 posted by Baker [75.118.7.231] on 2009/05/10 18:25:25
in an almost anti-climatic way -- after fixing 3 compile errors -- it's done.
Now all I need to do is FTP in my Mac and RAR up the source and post links here.
I imagine Spirit can compile the Linux version.
@Sleeperwalker
I was going to try and merge the two myself, but now it looks like I don't have to.
It should be set, but the project files and the source could use a quick look over on a rainy day.
I'll probably upload this here in 15 mins or so.
 Links
#137 posted by Baker [75.118.7.231] on 2009/05/10 18:57:10
#138 posted by Spirit [80.171.9.158] on 2009/05/10 21:03:55
I had to make one tiny change in net_sdlnet.c.
#include <SDL/SDL_net.h>
to
#include <SDL_net/SDL_net.h>
But this might be Debian's fault I guess.
http://www.quaddicted.com/engines/...
Careful, it's a tarbomb (well, just two files inside).
 SDL Gamedir Crash
#139 posted by Baker [75.118.7.231] on 2009/05/10 21:13:15
Spirit, on OS X FitzQuake SDL has always crashed if I do a gamedir change and then load a map.
If I do "game travail" and then "map start"
The map loads for a microsecond, FitzQuake SDL freezes and then in several seconds the app terminates.
Does the Linux SDL have this problem? I inquire because I'd like to take a look at fixing it (but I'm not that proficient debugging on a Mac, I know how to dump the memory on Windows but have no clue on OS X).
 Well
#140 posted by ijed [190.20.96.131] on 2009/05/11 01:32:10
Broken limits in multiplatform are now a thing of the dark ages then, or soon.
Good work.
#141 posted by Willem [24.163.61.78] on 2009/05/11 02:11:57
I tried it but I got 2 hard lock ups in a row on my Mac (at seemingly random times). Is there something I can post that would help you?
Like, the game would freeze in full screen and I had no way of getting back to my desktop.
 Willem
#142 posted by Baker [75.118.7.231] on 2009/05/11 03:40:39
I'm not so familiar with debugging on a Mac especially if I don't have the problem firsthand.
Updating the Fitz SDL 0.80 to Fitz SDL 0.85 mostly involved updating the rendering and protocol changes that Metlslime made in 0.85
The only freeze I have -- and I had this with 0.80 -- was trying to change gamedir via "game whatever" and then trying to play a map.
Questions:
1. Had you had this problem with FitzQuake SDL 080? (very important question, tells me whether something preexisting or new is likely cause of problem)
2. What were you playing? (What map? Is a gamedir involved? This will let me play the map).
3. Do you have the problem in windowed mode? I saw lots of Linux users have fullscreen issues in the FitzQuake SDL release thread.
4. What resolution are you using width/height/bpp?
Maybe Sleeperwalker will have some ideas.
 Good Job
#143 posted by negke [88.70.84.106] on 2009/05/11 09:01:53
Linux version works.
Request for future versions: the keyboard layout is still messed up on my German setting - some keys use the German layout, while others still use the English one. This means I can't type characters like quotation marks, for example, which is annoying in some situations. I wouldn't mind a non-localized layout.
Or can I fix this by using another keyboard setting ("dead acute" or whatever)?
#144 posted by Spirit [80.171.9.202] on 2009/05/11 09:38:26
Baker: Yes, I get a segfault too. I had that bug earlier and told sleepwalkr, forgot to check back though (or maybe I discovered it only after the 080 sdl release).
negke: "setxkbmap us" in the shell before launching. Don't forget to go back to "de" later. ;)
 Coitus Interruptus...
#145 posted by the silent [82.185.144.141] on 2009/05/11 10:01:46
Loaded Fitz085sdl on my mac, happy as a bird...
Still no chance of mapping the Command function... Oh, shit.
I'm a keyboardly impaired Fitz user...
 I Meant Command Key.
#146 posted by the silent [82.185.144.141] on 2009/05/11 10:02:11
Stupid me.
#147 posted by Willem [24.163.61.78] on 2009/05/11 11:29:35
Is there any way to fix that initial mouse weirdness? Whenever I load the game, moving the mouse the first time snaps wildly to some seemingly random position. From that point forward, it's fine. It's weird.
#148 posted by Willem [24.163.61.78] on 2009/05/11 11:29:53
And this isn't just on the new one. Fitz has always done this mouse thing for me.
 Hmmm...
#149 posted by the silent [82.185.144.141] on 2009/05/11 11:56:05
All engines do that for me.
 Max_edicts + Loadgame On SDL = Crash
#150 posted by Baker [75.118.7.231] on 2009/05/11 17:20:29
I've been trying to play through Warpspasm on OSX and on the 2 second level it obviously drops to console and complains about max_edicts which is 1024 by default.
If I start up FitzQuake SDL and change max_edicts and then load a game = crash.
If I start up FitzQuake SDL and leave max_edicts as-is and load a game = no crash.
Investigation continuing ...
 First Off
#151 posted by SleepwalkR [85.179.14.252] on 2009/05/12 15:37:27
Which version of SDL did you base this on? Metl and I were planning on waiting for SDL 3, because it has some useful new features.
The mouse thingy willem describes is a known issue. I had tried to fix it, but it didn't work. Don't imagine it to be too hard to fix though.
Keyboard mapping is difficult because you have to translate SDL key codes to Quake key codes. I intended to ditch Quake key codes and use SDL throughout, which would squash all those problems.
 FQ 0.85
#152 posted by metlslime [81.151.97.150] on 2009/05/12 20:17:33
I haven't read the small print but what is the difference between Protocol 15 and Protocol 666?
 @Sleeperwalker
#153 posted by Baker [75.118.7.231] on 2009/05/13 00:12:50
Which version of SDL did you base this on?
I just updated your version exactly as-is.
 Re: #152
#154 posted by metlslime [173.11.92.50] on 2009/05/13 00:37:52
Increased a handful of limits from 255 to 65535 (models, sounds, ammo, frames), allowed for edict limits above 8192, added per-entity alpha support, added high-precision aiming, and added a timing hint for interpolating models that aren't animating at 10Hz. I think that's it.
 Next/previous Weapons
#155 posted by anon [92.114.179.219] on 2009/05/15 22:43:19
hey guys,
I just picked up Quake with FitzQuake and I'm LOVING IT. Newb question: how do I bind the keys for next/previous weapon?
thanks!
 Post A New Fitz 0.85 SDL Thread ?
#156 posted by stevenaaus [203.55.33.219] on 2009/05/16 03:31:53
SDL FitQuake-0.85 seems to run ok for me :>. Finally i can piss off Darkplaces again - god that thing is slow.
First impressions: like the redone status bar, and it's very smooth - but maybe i'm just a little blotto tonight.
Here's a hack to allow for switching between fullscreen/window modes (SDL version) using the ALT-ENTER key combo. It's bloody rough, and may not apply cleanly because of tabs/spacing so ping me if there's any probs. I might get the inspiration to polish it up now i have the 0.85 source, but in case i don't/can't:
-------------------start of patch
--- keys.c.orig 2009-04-13 11:58:08.000000000 +1000
+++ keys.c 2009-04-13 12:18:28.000000000 +1000
@@ -1023,17 +1023,27 @@
}
// johnfitz -- alt-enter to toggle fullscreen. FIXME -- this does NOT work
-#if 0
- if (!down && (key == K_ENTER) && keydown[K_ALT])
- {
- extern cvar_t vid_fullscreen;
+// stevenaaus -- but this hack (from sf.net/uhexen2) for SDLFitz works for me. SDL ;>
+
+ if (!down && (key == K_ENTER) && keydown[K_ALT]) {
+
+ extern SDL_Surface *draw_context;
+ extern cvar_t vid_fullscreen;
+
+ // VID_Restart ();
+
+ S_ClearBuffer ();
+
+ if ( SDL_WM_ToggleFullScreen(draw_conte... > 0 )
+ {
if (vid_fullscreen.value)
- Cvar_Set ("vid_fullscreen", "0");
+ Cvar_Set ("vid_fullscreen", "0");
else
- Cvar_Set ("vid_fullscreen", "1");
- VID_Restart ();
+ Cvar_Set ("vid_fullscreen", "1");
+ } else {
+ Con_Printf ("SDL_WM_ToggleFullScreen failedn");
+ }
}
-#endif
// johnfitz
//
-------------------end of patch
 "game" Command Segfault *seems* Sound Related
#157 posted by stevenaaus [203.55.33.219] on 2009/05/16 03:32:52
I get a segfault too when using the "game" command to change games and then loading a map. I made a debug client and there's two backtraces below. Looking at them, I then tried running with "-nosound" and it f-ing works!
Hmmm.... I tested fitzquake-0.80 on FreeBSD and the diagnosis is the same: it only segfaults with sound enabled. But testing on my laptop (with the same OS as my desktop, AC97 sound and ATI mobility radeon), there's no segfault at all. I'm a little confused here, but this may indicate it has to do with CPU optimisations or memory structure allignments (this box is a Core 2 Duo, laptop is a PIII), but can't see anything too unusual happening really. Making with gcc3.4 is no diff.
Gdb reports "Program terminated with signal 11", which from the signal manpage ("man 7 signal"), is:
Signal 11 is "SIGSEGV 11 Core Invalid memory reference"
# gdb fitzquake core
--------------------
Program terminated with signal 11, Segmentation fault.
#0 GetLittleLong () at snd_mem.c:186
186 val = val + (*(data_p+1)<<8);
(gdb) bt
#0 GetLittleLong () at snd_mem.c:186
#1 0x0807522f in FindNextChunk (name=0x809d487 "cue ") at snd_mem.c:206
#2 0x08075434 in GetWavinfo (name=0xaf485850 "dragon/sight2.wav",
wav=0xb7045498 "RIFF];", wavlength=15205) at snd_mem.c:296
#3 0x080757e1 in S_LoadSound (s=0xaf485850) at snd_mem.c:128
#4 0x0806bd05 in S_PrecacheSound (name=0xbff68fec "dragon/sight2.wav") at
snd_dma.c:346
and othertimes:
Program terminated with signal 11, Segmentation fault.
#0 0xb7effd16 in glGetIntegerv () from /usr/lib/libGL.so.1
(gdb) bt
#0 0xb7effd16 in glGetIntegerv () from /usr/lib/libGL.so.1
#1 0x0805f823 in Draw_BeginDisc () at gl_draw.c:691
#2 0x0808e9e6 in COM_LoadFile (path=0xb44541d4 "sound/ambience/wind2.wav&quo...
usehunk=4)
at common.c:1649
#3 0x080757b1 in S_LoadSound (s=0xb50feb5c) at snd_mem.c:120
#4 0x0808440f in S_PaintChannels (endtime=139264) at snd_mix.c:189
 Anon - Weapon Change Commands
#158 posted by Mr Fribbles [121.44.213.121] on 2009/05/16 06:20:48
Welcome to fun!
Here's an example of the commands to change weapons. You can type them in the console or put them in your config files.
//cycle weapon forward
bind SHIFT "impulse 10"
//cycle weapon back
bind CTRL "impulse 12"
#159 posted by gb [89.27.223.196] on 2009/05/20 19:18:45
Metl, any chance at CSQC support in a future Fitzquake?
It would pretty much be at the top of my wish list. I believe the full potential of client-side qc hasn't really started to sink in, but it should.
Anything that uses custom keys or items could benefit from a nice looking inventory (instead of microscopic status bar slots) and an equally nice looking HUD.
Not to mention moving sounds (example: rockets emitting sound in flight, sound following trains, monsters etc) and stuff like completely new HUD elements controlled from qc.
Not to even remotely mention the possibility of choosing a player model etc. via a CSQC menu. (I know that Quake only has one player model, but that will change.)
As far as I know the stuff works by having a clientside progs.dat as well as a server side one.
 CSQC
#160 posted by Baker [75.118.7.231] on 2009/05/20 20:40:46
As time permits, Spike has a prototype CSQC WinQuake he gave me to do a test integration with ProQuake.
I'm pretty good at working with Avirox (QuakeC CSQC and FTE lover) and over the coming time there may be a standardized NetQuake implementation of CSQC with great docs and a good tutorial for engine authors to use.
Without this, really no one can implement CSQC and there certainly needs to be a standard implementation so any engine author's engine behaves in an expected manner.
This will unfold.
 YAY
#161 posted by gb [89.27.223.196] on 2009/05/21 06:27:19
That sounds great. Much better than anything I would have hoped for! :-)
 CSQC...
#162 posted by metlslime [24.130.223.174] on 2009/05/21 10:01:16
I'm hoping that someday I will add support for this. Right now the standard needs to actually be finalized. I am also looking forward to example implementations or tutorials that might spring into existence in the future.
 CSQC Will Likely Never Be Finalized
#163 posted by Lardarse [62.31.165.111] on 2009/05/21 14:27:56
At least not any time in the next few years...
 Standards
#164 posted by Baker [75.118.7.231] on 2009/05/22 01:49:53
It has to be finalized to be mainstream. You try the line somewhere, accept the limits and write up the specs.
The secret to success is to finish, standardize, educate.
Commercial companies are good at this because things have to shipped.
You can always do more, but at some point in time you have to pull the cake out of the oven and call it a day ...
... knowing is it better than what you have today.
DarkPlaces and FTE have many features and yet so few mods because they are impressive science projects with some level of stability but never reach done.
And that's fine except no one can't write up specs and documentation.
Perhaps the best thing about FitzQuake 0.80 is it didn't have updates for nearly 4 years, drawing a new "standard" and giving everyone time to adjust.
(yes fog, skyboxes, enhanced limits, lits isn't the world but no one targets glquake as the main engine in single player any more. Probably largely due to Fitzquake 0.80)
#165 posted by metlslime [173.11.92.50] on 2009/05/22 03:24:00
Perhaps the best thing about FitzQuake 0.80 is it didn't have updates for nearly 4 years
I hope that's not the best thing about it :P
 Context
#166 posted by Baker [75.118.7.231] on 2009/05/22 03:34:26
Haha ;)
Context, context, context ...
#167 posted by metlslime [173.11.92.50] on 2009/05/22 04:20:54
but I agree, standards are important and if an engine implements something without a standard, that implementation can become a standard. It mostly depends on what content (maps/mods) actually use the feature.
I have tried to be cautious about adding crazy new features, and luckily most of the features I've added had a near-complete standard for how they worked (lit files, skybox, fog, external textures, .alpha, etc.)
When I do have to do my own thing (new protocol) I try to at least make it sane, and in the case of the protocol, I tried to add as much as possible in the first version to reduce the need to constantly make new protocol versions which only add one new feature.
Bumping limits is a stealthy way to set (or break) informal standards of course, and luckily aguirRe's engine has stabilized on which limits it bumps, and I was able to mostly bump all of those limits in a single release.
#168 posted by anon [92.114.179.219] on 2009/05/24 21:50:02
hey, this is anon again..
don't know if this is a bug or just me being stupid BUT, upon completing all of the episodes/runes nothing happens. Specifically, I get back to "Introduction" and the last two episodes are locked (passed). The rest are open, even though I clearly remember them being locked upon completion. Also I only see 2 runes in the HUD.
Wazgoingon?
#169 posted by Spirit [80.171.95.207] on 2009/05/24 21:55:11
You accidentally launched a new game after completing episode 2 and did not notice.
 Or
#170 posted by Lardarse [62.31.165.111] on 2009/05/24 23:20:55
You saved somewhere other than the start map. Which doesn't work too well...
#171 posted by Spirit [213.39.223.153] on 2009/05/29 09:08:44
Old Mobility Radeon (gonna check the type later).
Driver: 6.14.10.6430
gl_clear 1 makes the game run ultra slow (think ~1 fps) in 32 bpp. In 16bpp it is slightly better (3-4fps I guess).
 Bah
#172 posted by Spirit [80.171.51.164] on 2009/05/29 16:19:58
No idea what type the chip is.
M6, 1002-4C59, 1028-00E3 (Dell Latitude something 610)
This is a new bug in 085. 080 works fine.
 Re: Bah
#173 posted by FreonTrip [69.15.252.226] on 2009/06/10 16:08:23
The M6 Radeon is a mobile derivative of the Radeon 7000. Whatever the bug is, if it's on the Win32 driver side then it won't be fixed. I'd probably just keep gl_clear set to 0 until metlslime has had a chance to look at it.
 Regarding #171 / #173
#174 posted by metlslime [173.11.92.50] on 2009/06/10 23:59:02
is this a bug specific to fitzquake 0.85 or do other fitzquakes (or glquake and derivatives) do it too?
#175 posted by Spirit [80.171.27.36] on 2009/06/11 09:51:02
Fitzquake 085 only.
It seems related to how Fitzquake sets the resolution.
If I launch it with -width xxx -height xxx -bpp xx it works fine.
If I launch it normally, it does it's resolution change flicker and then runs so slow. I also noticed that the loading pentagram in the top right corner (always?) shows in funky colours then (like a normal map). Also a part on top of the display might flicker a bit.
PS: Setting a windowed mode with 16bpp when Windows is 32bpp is not fun. :P
 SDL Buggy Sound ?
#176 posted by stevenaaus [203.55.33.245] on 2009/06/15 01:19:51
Testing large maps with FitzSDL-0.85beta on my desktop i'm getting quite a few crashes, sometimes every 5 minutes. And it just killed Xorg/Linux on my laptop while playing "timedemo demo1".
Hmmm... playing "-nosound" and have yet to get a crash. (Still.. negations can't prove a theory).
 Metlslime
#177 posted by JPL [82.234.167.238] on 2009/06/27 11:11:19
I played multiplayer some days ago at office with FitzQuake0.85... it was running like a charm till it hang up, without any possibilities to unblock the game, except Ctrl+Alt+Del, and kill the process... and no error message at all... Maybe a network protocol issue, or something else, not sure...
Did you ever had heard about such issue before ?
 JPL:
#178 posted by metlslime [71.202.219.105] on 2009/06/29 09:22:58
no, never heard of that. Can you tell me what map, what mod, and what you were doing at that moment?
 Metlslime
#179 posted by JPL [213.30.139.243] on 2009/06/29 09:44:58
Hang up happened twice with 2 different mods: Reaper 0.80 and Killer 0.90.
The map was THF the first time, and DM3 the second time.
I was just running (bunny-hopping) and firing spikes with SNG on an another guy the first time, and the second I was ambushed with RL..
I am actually trying to educate my collegues at Quake DM at office :)
 Monster Movement Animation
#180 posted by Jaromir83 [87.249.151.200] on 2009/07/04 20:33:38
kinda liked the laggy monster movement animation v0.8 provided more than smooh v0.85 one. any way to set the imprefect monster movement at v.085 pls? would really like to downgrade this feature. thanks
#181 posted by onetruepurple [83.25.253.50] on 2009/07/04 20:51:26
r_lerpmodels 0
r_lerpmove 0
 Oh Yeah...
#182 posted by metlslime [71.202.219.105] on 2009/07/04 23:16:56
the documentation states that they both default to 0, but it is wrong, they default to 1 :P
 Some Kind Of Bug
#183 posted by necros [99.227.133.158] on 2009/07/04 23:53:07
i'm not certain, but i believe i've found some kind of odd bug to do with .blocked for doors.
this happens in fitzquake, but not in aguire's glquake, which leads me to believe it's a bug with the engine.
basically, you get crushed by a door when you're standing on top of it while it is traveling downwards. this shouldn't be able to happen since you can't block a door in that manner.
the instance where this was happening was originally in a map that was breaking many limits, but i've transplanted the bit of map into a seperate map and the problem still occurs...
any idea what this is? i can give you the bsp/map if you're interested.
 Necros
#184 posted by Preach [81.153.27.192] on 2009/07/05 00:15:51
Have you increased your max FPS at all? At very high framerates glitches like that can start to appear, and it might be that aguirre's engine keeps a hard cap on server frames. If you can reproduce it at 72 fps then it isn't that.
 Necros:
#185 posted by metlslime [71.202.219.105] on 2009/07/05 00:23:32
if you can upload the map somewhere and email me the URL, that would be useful. (or just mail it to me if that's easier for you.)
Also what Preach said.
 Very Interesting...
#186 posted by necros [99.227.133.158] on 2009/07/05 00:41:10
my host_maxfps was set at the default 72.
i set it to 10 and 60 and the bug didn't happen.
setting it to 71 (and 70, 69) makes it happen at a different spot, but setting it to 68 makes it go away, however, i get a single 'unstuck' message as the door hits the top of it's movement so i think it still has the potential to happen.
i'll send you the stuff in the mail.
 Mm
#187 posted by necros [99.227.133.158] on 2009/07/05 00:50:27
should have thought to test this sooner, but the bug also happens in normal glquake.
i'm pretty confused right now, because i've never had this problem before. i'm trying to figure out if i've built something different somehow, but as far as i can tell, it's the exact same combo of entities i've used many times before. o.o
#188 posted by Willem [24.163.61.78] on 2009/07/05 01:41:48
Yes, this happens at the start of Drew's speed map and at the start of White Room as well. Any kind of long distance door like that which you ride downwards has the potential to start hurting you for no apparent reason. It sucks.
 Ah, Okay...
#189 posted by metlslime [71.202.219.105] on 2009/07/05 04:22:04
it's good to know it's not a bug i personally created. Still good to know about it, though.
 Directional Dependent Music
#190 posted by grahf [74.127.72.91] on 2009/07/08 04:24:22
So I'm finally playing warpspasm on fitzquake .85 sdl mac beta, and it's lovely (the way it was meant to be played, no less), but I notice that the background music is directional; that is, I only fully hear it facing a certain direction.
I don't know if this is an issue with fitz or warp, but I confirmed that it doesn't happen playing warpspasm in Darkplaces.
 Grahf:
#191 posted by metlslime [64.175.155.252] on 2009/07/08 05:02:10
It's an issue with all engines that don't do something special to fix it. Basically all sounds in the level have an origin point, even if they are attenuation = 0 sounds. I don't know what darkplaces does specifically to fix it, but it must treat those sounds specially, forcing them to be the same volume in both channels.
 Yeah
#192 posted by ijed [190.20.115.93] on 2009/07/08 05:38:58
I hacked it by putting four sound entities in each level, at the primary cardinal points.
The best fix is a fair bit of messing about - null sounds and playing them from outside. But nothing breaks immersion like alt-tabbing.
Basically sounds in quake can only be heard when seen. ATTN_NONE makes them full volume despite distance.
 Thanks Guys
#193 posted by grahf [74.127.72.91] on 2009/07/08 06:00:26
I suspected it had something to do with attenuation. It didn't really detract from the atmosphere anyways, I was just curious.
Keep up the good work and all; I really appreciate and enjoy it.
 #177 / 179
#194 posted by JPL [213.30.139.243] on 2009/07/08 07:44:10
metlslime, I made others tests in multiplayer.
I played with 5 collegues, and no errors / hang up / issues occured during more than an hour, hence the fact I think the issue comes from the mods itself... weird...
#195 posted by Spirit [213.39.223.24] on 2009/07/08 09:02:45
That's why more engines need Ogg Vorbis cdtrack emulation (with cd play # support).
 Full Dark Torches
#196 posted by necros [99.227.133.158] on 2009/07/12 02:37:45
what causes that? every so often, a wall torch (or quoth brazier) is full dark, even though the floor directly under it is very bright.
 Maybe..
#197 posted by JPL [77.196.179.215] on 2009/07/12 12:11:33
... because it is in a wall ? I already experimented this dark-ish behavior with impaled corpses... maybe same issue.. though... :P
#198 posted by necros [99.227.133.158] on 2009/07/12 20:47:11
here's a screenshot: http://necros.quaddicted.com/temp/...
as you can see, the entity is inside the level (the origin on the braziers is up where the flame is) and the floor underneath is nearly full brightness.
it doesn't happen in aguirre's glquake though.
 Necros:
#199 posted by metlslime [71.202.219.105] on 2009/07/13 03:08:55
so this is a fitzquake-only bug? Perhaps it's due to entity lighting interpolation (the code that uses the floor lightmap brightness to determine lighting, in fitzquake interpolates between neighboring lightmap samples.)
 Well
#200 posted by necros [99.227.133.158] on 2009/07/13 04:04:57
i am hesitant to declare it's a fitz only bug since i can only really test in fq and aguirreGlquake (henceforth aglq, curse you aguirre for never actually naming your engine!). do the tools used to compile (in this case, aguirre's light util) make a difference when the engine reads the data?
otoh, i cannot ever remember seeing this happen in glquake. the 'zone' where an entity is full dark also appears to be more than just a single pixel or whatever. i've had it continue to happen up to 16~ units away from where i first noticed it.
in any case, if it's interpolating, then it's definitely not getting some lightmap data at all since that entire area is full of light.
 Hmm...
#201 posted by necros [99.227.133.158] on 2009/07/13 04:16:52
ok, too look at this a different way, perhaps it's interpolating with lightmaps on surfaces not parallel to that floor.
this is an unsealed map, so there are 2 planes, one that is the bottom of the wall brushes, and one that is the side of the floor brush. those 2 planes/collection of faces are full dark.
 Stupid Question But...
#202 posted by JPL [77.196.179.215] on 2009/07/13 10:21:34
.. did you add an angle value to give direction to the light ? It may explain the issue...
Also, I remember (correct me if i'm wrong) that depending of the light tool, the angle / mangle, anglesense / etc.. fields may be interpreted differently by different light tool... though...
 Quake Mission Packs ...
#203 posted by micpringle [213.120.90.59] on 2009/07/13 10:29:02
Is FitzQuake capable of running the official Quake mission packs (Armagon / Dissolution) ?
From what I understand one of the packs requires a change to the engine to allow rotating brushes and I was hoping this change has been implemented in FitzQuake ?
I'm currently running 0.80 SDL on a mac and I'm not sure if 0.85 SDL has been released yet.
-Mic
 Micpringle:
#204 posted by metlslime [71.202.219.105] on 2009/07/13 10:33:45
yes, it supports them -- the engine change was already in the source code when id software released it.
 Metlslime ...
#205 posted by micpringle [213.120.90.59] on 2009/07/13 12:18:50
Fantastic - Thanks for the quick response.
On another note, I sent you an email a few days ago regarding FitzQuake and I was wondering if you'd managed to get chance to read it ?
Thanks
-Mic
 How Do I
#206 posted by ijed [190.20.105.43] on 2009/07/18 21:45:13
Raise maxplayers in fitz? Setting it to 10 just tells me 'maxplayers set to 4'.
#207 posted by mwh [118.92.164.253] on 2009/07/19 09:23:30
In bog standard quake at least you can only raise the limit above 4 on the command line: -maxplayers 6
It only goes to 8 though, I think.
 Ijed
#208 posted by spy [92.47.218.46] on 2009/07/19 10:00:51
'-listen 16' will do it for you
 Thanks
#209 posted by ijed [190.20.117.227] on 2009/07/19 18:04:14
 Model Limits ...
#210 posted by micpringle [213.120.90.59] on 2009/07/28 10:07:14
Hi,
What are the model limits in FitzQuake in terms of vertices/triangle/faces etc ?
(I'm specifically refering to .mdl models)
Thanks
-Mic
 Fog
#211 posted by erc [94.122.182.187] on 2009/08/07 17:35:48
Seems like the engine doesn't read my preferred fog value from autoexec, even though it has no problems with other related cvars, like r_skyfog. Any suggestions metl?
 Erc:
#212 posted by metlslime [173.11.92.50] on 2009/08/07 23:16:29
fog gets cleared on map load, so it's becuase autoexec happens before you load whatever map you want to play.
I've had other questions/requests like this, it seems like people want to use fog as a user preference rather than as a mapper testing feature, so i probably need to figure out a way to do this. Probably need to track whether the current fog value was set from the console vs. the worldspawn, and clear it only if it was set in the worldspawn. Of course this breaks any mod that uses stuffcmd to hack fog into a level, maybe i need to publicise SVC_FOG so that doesn't happen....
 Remember
#213 posted by ijed [216.241.20.2] on 2009/08/07 23:24:57
That some mods will change fog as well - Quoth's trigger_iforgetwhatitscalled can change the fog.
 Metl:
#214 posted by erc [94.122.182.187] on 2009/08/07 23:58:04
Thanks for the explanation. I remember trying out some 'fancy' engines years ago - those kept the fog throughout the map changes once it was enabled from the main menu. I didn't know it was a complicated issue till you explained it to me. It isn't that important anyway, just a minor annoyance that can be easily dealt thru' the use of a simple alias. Even though I prefer playing custom levels the way they're intended to, I thought minimal use of fog would spicen things up a bit when replaying the classics.
 Re: 213
#215 posted by necros [99.227.133.158] on 2009/08/08 00:09:00
i'm kicking myself that i never made an info_interpolateFogValues :P
 It Was Good
#216 posted by ijed [190.20.124.85] on 2009/08/08 03:32:29
In Lazarus, but the only way to make it really work visually was to trap the player in a lift whilst it interpolates.
 Windows 7
#217 posted by Jago [84.249.95.211] on 2009/08/09 06:36:18
I have just finished doing a round of benchmarking using the Windows 7 RTM.
1680x1050x32:
FitzQuake: timedemo demo1: 1227 fps
:O
Curiously, on Windows Vista SP2, I was getting roughly 400-500fps using the same config and same hardware and was thinking that the engine plain doesn't scale any further anymore. But apparently you can squeeze a fair bit out of it with new underlying OS tech.
Specs:
Core 2 Duo E6600 2,4 Ghz, 4gb ram, NVIDIA 8800 GTS
 And For The Curious
#218 posted by Jago [84.249.95.211] on 2009/08/09 06:38:07
I am seeing a 3-10% performance increase in Windows 7 compared to Vista across the board, depending on the game. However, Quake and Quake 3 stand out in an absurd fashion.
FitzQuake: 400-500 fps => 1227 fps
Quake3: 380fps => 775 fps
#219 posted by necros [99.227.133.158] on 2009/08/11 22:15:45
does 0.85 support external textures for sprites? couldn't find it in the documentation, so it probably doesn't, but on the off chance it does..?
 Necros:
#220 posted by metlslime [173.11.92.50] on 2009/08/12 01:08:16
no, it doesn't. 0.90 maybe :)
 Cool :)
#221 posted by necros [99.227.133.158] on 2009/08/12 02:32:51
about external textures though...
why do they seem to be lit in a slightly different way from embedded textures? it's hard to describe, but they seem universally darker and don't seem to get over-lit like embedded textures. they seem to be like old glquake where lighting caps out at 100% light.
any chance 0.90 could help smooth out those differences to make embedded and external textures more similar in game?
 Necros:
#222 posted by metlslime [173.11.92.50] on 2009/08/12 04:30:56
that's suprising to me, the lighting should be the same on both types of textures.
If you're using idgamma, then that would explain it, since it alters the appearance of all quake image files without affecting any external replacement images.
 Jago
#223 posted by jdhack [75.155.253.195] on 2009/08/16 20:44:06
Any chance you could run that test on XP too? The cynic in me suspects that the speed boost has less to do with Win7's improvements than it does with Vista's (how to put this delicately?) crapiness.
 Jdhack
#224 posted by Jago [84.249.95.211] on 2009/08/17 04:15:46
No, I am not going to be install XP on this machine :)
 Fps Related Problems
#225 posted by rudl [91.115.238.248] on 2009/08/23 13:56:53
On my Pc I have some problems that only appear at high framerates, with 120fps it starts and with 500-700fps it gets really really anoying.
so host_maxfps is set to 999
vsync=off
When walking on a ramp like in E1M1 with those buttons the movement becomes really strange I simply can't move forward I have to jump down those ramps. This happens only at high fps rates like 500+, but at 200 fps at the start of the downward ramps there is a little bit of lag. at 60fps everything runs fine.
I noticed another problem in sm155_ankh, it seems that I get hurt by the elevators when standing on them, in fact it becomes unplayable, the problem does not occur with vsync=1 /60fps.
Those problems seem to happen with aglquake too. However with darkplaces it runs fine even at higher framerates.
Testet on vista32 and Ubuntu 9.04 32
gfx card 9600gtgreen driver 190.38win 185.18.36lin
 Shouldnt
#226 posted by nitin [124.168.31.214] on 2009/08/23 14:09:43
host_maxfps be left at 72?
#227 posted by necros [99.227.133.158] on 2009/09/08 07:52:55
per-entity alpha doesn't work on sprites?
what if a setting != 1 (or 0) would change blending mode on sprites to additive and then, depending on the alpha variable, multiply the sprite's pixel colours by a shade of gray corresponding between 0 and 1?
or just make it do what you did for brushes and models? :P
 Necros:
#228 posted by metlslime [98.248.107.212] on 2009/09/08 09:35:47
it can be done with alpha blending, and will probably make it into a future version. The reason it's not in there now is it seemed less important than the other entity types and i was trying to wrap up that version so i could actually Ship It.
#229 posted by necros [99.227.133.158] on 2009/09/08 10:19:14
that's cool. it's not like it's a huge problem or anything. brushes and models are more important, as you said.
still, it was odd that alpha wasn't supported for all types of entities, which is the only reason i brought it up. :)
#230 posted by necros [99.227.133.158] on 2009/10/11 01:26:29
just a question, in the fq085 readme, it says:
fixed sliding around while standing on solid entities' bounding boxes (monsters, players, etc)
but it's not actually fixed. was this a planned feature or something that was scrapped?
 Necros
#231 posted by metlslime [98.248.107.212] on 2009/10/11 01:30:22
That was fixed in a really early version (like 0.60 or something)and later reverted when I realized it had side effects. I am now more cautious about changes that affect gameplay. Plus I think thus can be fixed in qc instead.
#232 posted by necros [99.227.133.158] on 2009/10/11 02:10:36
yeah, i can be. i was only wondering if it was going to be re-added and if it was worth skipping the qc fix.
#233 posted by metlslime [173.11.92.50] on 2009/10/11 02:18:33
I think i'd have to be convinced that it would be a good idea to re-fix it in the engine, since it seems like that would just lead to inconsistent behavior across engines. Probably better to fix in in qc so that it works in all engines.
#234 posted by meTch [69.183.59.39] on 2009/10/11 15:15:08
in runequake its fixed so u don't slide on players heads
leads to great towers of players now and then
 Keep The Sliding.
#235 posted by PM [72.216.13.139] on 2009/10/14 16:17:26
Players standing on monsters and the like as if standing on the ground is a potential gameplay changer. Players can use such entities as platforms to reach places more easily or are otherwise inaccessible.
I would rather see the "fix" either left out, or included as an option, with the fix turned off as default. One reason why I play FitzQuake is it has useful features such as frame interpolation and increased limits while retaining the behavior and feel of the original engine.
 Scrag Riding Would Function Finally
#236 posted by Ankh [192.100.112.202] on 2009/10/14 16:39:37
with this fix
 PM:
#237 posted by metlslime [173.11.92.50] on 2009/10/14 21:36:09
i think, if i ever revisit some of this stuff, i will follow the Darkplaces method of having a seperate cvar for each gameplay-changing "fix" so that you can turn them off as you wish.
#238 posted by necros [99.227.133.158] on 2009/10/18 03:35:59
here i am again... :P
this bug (at least, i believe it is a bug) is very strange. specifically, i experience a large performance drop (1ms frames become 20ms frames and the pentagram icon appears) in start.bsp when the light_flame_large_yellow in those 2 big braziers next to the start point are in the pvs on the first loadup of the map. they also, sometimes (depending on your position and view angle), appear partially black except for a few pixels.
if you walk to the end where the normal skill teleporter is (but don't take the teleporter), the light_flame_large_yellow entities disappear out of the pvs (from vis) and performance goes back to normal.
if you restart the map (either by suiciding or restart command), two things happen.
1. the wall torches on the dividing pillars facing the start point turn black, but only on that last frame as the map is reloading. (you see it as the frame is displayed while loading, i mean)
2. the performance drop goes away as does the black pixels problem. (which i am guessing are linked?)
now, here's the complicated part. this happens in a mod, and doesn't happen in stock progs.
this performance drop is a recent developement though, afaik.
so, onto some more weirdness:
the mod allows you to spawn a 'pet' fiend. now, if you load start.bsp (performance drop now) then reload the map (performance drop is gone) and then spawn the fiend, the performance drop is back!
now, if you walk back to the normal skill teleporter and the light flames disappear from the pvs, the performance drop is gone!
also, if the pet fiend goes out of the pvs, while the flames are in the pvs, the performance drop also goes away.
some final info, as it may be relevant:
the player model is also custom with above average vertices and faces and gl_nocolor is 1.
finally, the 'pet' fiend uses a new movetogoal function:
void(float step) movetogoal_ext =
{
local float stepIncrement, stepRemain, tempYaw;
if (step > 10)
stepIncrement = step / 10;
else
stepIncrement = 1;
stepRemain = 0;
tempYaw = self.angles_y;
while(step > stepRemain)
{
movetogoal_builtin(stepIncrement);
stepRemain = stepRemain + stepIncrement;
}
self.angles_y = tempYaw;
ChangeYaw();
}
(movetogoal_builtin is the original function)
so you can see, multiple calls to movetogoal are happening in a single frame.
if you replace this with the old movetogoal, the performance drop doesn't happen when spawning the pet fiend, but the performance drop is still present when first loading start.bsp.
any ideas? o.0 i know this is technically my fault as it's a mod, but the occurrence is so strange and unique, i felt i should post about it. :P
 Heh
#239 posted by necros [99.227.133.158] on 2009/10/18 03:41:48
as always happens when i post about some bug or whatever, i figure out what was wrong. o.o
my heapsize was too small. 9_9
#240 posted by stevenaaus [110.20.62.23] on 2009/10/18 05:21:35
Why isn't heapsize init-ed to something bigger by default. I know FitzQuake is conservative in some ways, but couldn't this be done ?
 Stevenaaus:
#241 posted by metlslime [98.248.107.212] on 2009/10/18 06:41:01
I guess i could; in the past i've just assumed that my users are people that switched from glquake, so they already know how to configure settings that were present in glquake (heapsize, gl_flashblend, etc.) On the other hand, maybe that's not true and maybe many people don't know about those types of settings. If they don't, then I guess i need to figure out the best way to have defaults for those settings which satisfy the most people possible.
#242 posted by Willem [24.163.61.78] on 2009/10/18 13:18:18
I think defaulting to values that the average machine these days can handle is smart. I hate whenever I have to pass in -heapsize. It irritates me because I can't believe I'm still doing it in 2009. :)
#243 posted by mh [89.19.65.18] on 2009/10/18 15:16:09
64 MB heapsize seems reasonable these days, and should be enough to handle all but the most extreme cases.
#244 posted by Willem [24.163.61.78] on 2009/10/18 17:54:11
Especially considering that machines these days come with a few GB of RAM standard. Seriously, jack the default up to 128MB and be done with it. :)
#245 posted by necros [99.227.133.158] on 2009/10/18 19:37:22
for me, i never even thought about it because i never actually run the executable itself.
i always have my fq.bat file which does things like -particles 10000 -heapsize 64000 -bpp32 etc etc.
if you wanted to make the stuff standard, that's cool, but it doesn't bother me either way. :)
 Yup
#246 posted by SleepwalkR [85.179.25.223] on 2009/10/19 09:12:56
I was thinking about adding permanent parameters to the next version of fitz sdl on mac. There would be a preferences dialog where you can set some permanent parameters, and then add other parameters using the standard launcher dialog.
 Heapsize
#247 posted by mh [78.152.251.164] on 2009/10/20 01:01:45
Well it's not DOS anymore, even a 32-bit OS will be able to address ~4GB of virtual memory, irrespective of how much actual physical memory you have. Using a heapsize of 128MB is enough to run warpc with quite a bit of headroom (you can squeeze it into 64MB if your engine is careful enough about what it allocs), so I'm wondering is there any requirement for this command-line option to even exist any more? My own engine got rid of it a good while back, but then I use my own custom allocators which are NOT a trivial thing to write.
#248 posted by Willem [24.163.61.78] on 2009/10/20 01:03:40
Who doesn't have 128MB oF RAM? Seriously, it's time to just set it to something huge and move on. :)
#249 posted by necros [99.227.133.158] on 2009/10/20 04:20:34
is there a way to dynamically set it?
i mean, it would be pretty bad ass if the engine just reallocated everything if it ran out of room automatically... ^_^;
 Yeah...
#250 posted by metlslime [173.11.92.50] on 2009/10/20 04:47:39
writing a whole new memory system would solve this :P
 EzQuake
#251 posted by Baker [99.54.148.29] on 2009/10/20 04:57:28
Has some code IFDEF'd labelled "DarkPlaces memory manager" that dynamically allocates memory as needed.
 Memory
#252 posted by mh [89.19.72.245] on 2009/10/20 18:21:32
Oh, dynamically allocating as needed is easy. Keeping track of what memory you have allocated, freeing it in the correct places, keeping contiguous blocks where needed, ensuring nothing gets stomped, and transitioning from Quake's cache/hunk/zone system - that's hard.
It's the kind of thing where - unless you *REALLY* need it, or unless it scratches some particular itch you have - you might be better off just upping the default Heapsize.
#253 posted by mh [78.152.226.27] on 2009/10/20 22:25:05
I forgot "...and doing it all efficiently..." :)
 If It Works ...
#254 posted by Baker [99.54.148.29] on 2009/10/20 22:53:59
The ezQuake #IFDEF DARKPLACES_MEMORY_MANAGER code -- if it works -- is rather simple.
Shockingly simple, actually.
 Alias Models + External Textures
#255 posted by Baker [69.223.180.88] on 2009/11/05 07:13:11
Does FitzQuake support external textures for alias models?
/Btw ... FitzQuake is about the only non-DarkPlaces engine that renders a skybox when submerged in a liquid with r_wateralpha < 1. I never had a doubt ;)
 Argh .. Nevermind
#256 posted by Baker [69.223.180.88] on 2009/11/05 07:22:21
I thought this was added in 0.85
 Regarding -heapsize And Such
#257 posted by Jago [194.86.38.38] on 2009/11/05 12:50:29
Is there any particular reason why things like -heapsize aren't automatic and dynamic?
#258 posted by Spirit [213.39.219.228] on 2009/11/05 15:10:59
Yes, check 5 posts above yours.
 This Thread Beats The Record Folks
#259 posted by QMD [70.49.52.109] on 2009/11/12 02:57:03
On september 16, year 2000, 'maiden' posted the #237 message on the infamous thread at Qmap, called:
- - - - - - - - - - - - - - - - - - - - - - -
QuakemapDesigner... Err Designs Quake Maps.
Posted by Shambler [194.112.32.102], 31/08/2000 09:13 GMT
" The modestly named QuakeMapDesigner has been shouting about the Quake maps he's, err, designed at his QuakeMapDesigner site. They look like deathmatch and/or CTF maps to be (though I can't be sure), and QMD is after some reviews, so be sure to pick up some maps and give him an honest appraisal of their quality.
P.S. He's French apparently - any relation to you, Bal?? =) "
- - - - - - - - - - - - - - - - - - - - - - -
So just for you to remember the " good old days " folks and congrats on this thread, because it has a higher number of posting message.
Cheers!
QMD
"Where imagination means, levels!"
P.S.: QMD stands for "QuakeMapdesigner" and not " Quick Masturbation Discharge ".
 Crikey!
#260 posted by RickyT23 [81.159.214.189] on 2009/11/12 10:29:12
When that message was posted I was running around, truant from 6th form, popping magic pills and sleeping in every day.
#261 posted by mh [78.152.239.231] on 2009/11/13 23:38:03
"FitzQuake is about the only non-DarkPlaces engine that renders a skybox when submerged in a liquid with r_wateralpha < 1."
No it isn't. ;)
 Weird...
#262 posted by metlslime [173.11.92.50] on 2009/11/14 01:33:29
i'm not even sure why any engine would fail to draw the skybox when underwater, unless they specifically added code to do it. Otherwise you'd think that "if sky polygons are visible, draw skybox" is the most obvious logic. Or even the more dumb and simple "always draw the skybox" approach.
 User Error
#263 posted by Baker [69.19.14.21] on 2009/11/14 03:19:31
I had underwater fog on and didn't make the connection between that and the traditional fog. Skyboxes are viewed as infinitely far away. JoeQuake, Qrack, FuhQuake, ezQuake just draw the underwater fog.
And I believe none of the above even draw the skybox with any fog setting.
Bad post on my part!
 True Tho
#264 posted by RickyT23 [82.2.88.161] on 2009/11/14 03:56:29
#265 posted by mh [78.152.239.66] on 2009/11/15 14:52:11
Yeah, fog needs tweaking for an infinitely distant skybox, and at the very least the fog end value needs tweaking also even without an infinitely distant one. Haven't looked at FQ's skybox code yet but I wouldn't be too surprised if it did something like double the fog end value when drawing the sky.
 Some FQ 0.85 Bugs
#266 posted by mh [78.152.251.127] on 2009/11/15 21:02:52
In TexMgr_LoadImage8 you have "if (glt->flags & TEXPREF_ALPHA && !(glt->flags & TEXPREF_CONCHARS))" (also the same in a few other places) - "glt->flags & TEXPREF_ALPHA" needs parentheses.
 More Bugs
#267 posted by mh [78.152.251.127] on 2009/11/15 21:20:18
The initial value of gl_max_anisotropy should be 1. This fixes the infinite loop in the cvar callback and is conformant with the spec (i.e. a value of 1 specifies normal isotropic filtering).
 Mh:
#268 posted by metlslime [98.248.107.212] on 2009/11/15 21:50:15
fitzquake disabled gl_fog and just does a fixed-opacity blend over the sky, unless gl_skyfog is 1 (fully fogged) and then it just draws solid-colored, textureless sky polys.
As for the other bugs, thanks... i'll have to check those out.
 So
#269 posted by ijed [190.20.97.210] on 2009/11/17 03:24:32
Just learned that there's a 256 frame limit which seems to be an engine side cap.
Going to make changes to have the thing fixed on our end, but thought I'd ask - is there any reason not to fix it? Apart from the obvious 'hardly anyone wants 256+ frames of animation'.
 Ijed:
#270 posted by metlslime [98.248.107.212] on 2009/11/17 09:57:07
That limit was raised in protocol 666, and the frames seem to always be passed as 32-bit ints internally, so i'm not sure what the problem would be. Is it crashing?
 Yeah
#271 posted by ijed [216.241.20.2] on 2009/11/17 14:00:13
Without a warning and only when I add more than 256 frames. I thought I remembered something about it being mentioned in documentation but couldn't find it again.
In any case the model is going on a diet - there are some unnecessary frames in there that can be pruned. Just thought I'd mention it.
 Frame Reduction
#272 posted by Preach [94.192.82.29] on 2009/11/17 20:05:20
One trick you can use to get rid of frames is to create framegroups from some animations. The safest candidate is the stand animation, since there's no action the monster performs which needs to be synced with the frames. Anything more complicated than that would almost always cause difficulties, but that one should be safe enough. If you're only 8 or 10 over the limit, that might just get you back.
Once you know that trick, you can also make longer idle animations, knowing that they will only cost you one frame. I've not done it yet, but it's one of those ideas that's been knocking about...
 Interesting
#273 posted by ijed [216.241.20.2] on 2009/11/17 20:55:25
That's a cool idea - although there are actions that need to be run like idle sounds, and we've got some idle tic stands as well.
Having said that there's some stuff that can use it such as the simpler trap style entities like wasps, spikemines and maggots.
 Ijed...
#274 posted by metlslime [64.175.155.252] on 2009/11/17 22:24:37
okay, i'll look into it. Thanks for the report.
 FitzQuake 0.85 With MP3 Playback
#275 posted by Baker [99.30.141.155] on 2009/11/18 15:43:58
#276 posted by necros [99.227.133.158] on 2009/11/18 20:27:14
cool! thanks! :D
 Excellent Work! A Fog Question...
#277 posted by mnemonic [69.205.146.149] on 2009/11/28 04:34:12
Hey, just d/l'd FQ 0.85 the other day after wanting to run through a little Quake SP and remembering I didn't really like DarkPlaces last time I messed with it.
Anyway, FitzQuake has just replaced DP for me. :D
I'm having one problem, though - can't seem to get my fog settings to stick (tried it in both autoexec and in config after figuring out that scr_crosshairscale had to be changed there :D. Anyone have an idea why fog density wouldn't stay set? R,G,and B seem to stay set, fwiw.
System specs: XP Pro, A64 X2, 2GB DDR & 8800GTS 512.
Other than that, FQ works a lot like the UGL Quake I loved back in the day, but MUCH nicer (love the working fullbrights and gamma)- Thanks for the updated version!
 Mneumonic:
#278 posted by metlslime [166.205.138.150] on 2009/11/28 08:32:28
That's a known issue, the current behavior is for each map load to set the fog based on it's setting, and if it has no setting, it gets reset.
 Thanks For The Answer!
#279 posted by mnemonic [69.205.146.149] on 2009/11/28 18:15:49
I should have guessed it was something like that, since everything else works quite well. I'll just make a keybind for it if I find myself really missing it. :D Also wow, your update feels like Quake the way it was back in '95, thanks again!
(Now, time to drop some of CZG's, Vondur's and Elek's maps in to try 'em all out again...)
 Don't Forget
#280 posted by ijed [190.20.119.214] on 2009/11/28 22:33:42
Travail, Quoth and Tronyn's latest efforts :)
 Signon
#281 posted by MadFox [84.26.170.230] on 2009/12/09 00:05:56
I receive an error I didn't know, as it appears only in hard skill
8062 byte signonbuffer exceeded the standaard limit of 7998
Aguier's glquake doesn't give a message.
Is it the same as too many eddicts?
 Madfox:
#282 posted by metlslime [173.11.92.50] on 2009/12/09 01:30:40
no, it just means the overall level has enough stuff that the initial message to new clients is too big.
BUT: if you don't get this warning in aguirre quake, it might be okay. Try in fitzquake using sv_protocol 15 for a more accurate test, or just try it in regular quake (glquake or winquake) and see if it crashes. If it doesn't crash, i think you're okay.
 Surprised Player Who Never Knew New Clients Looked Over Shoulders Of
#283 posted by MadFox [84.26.170.230] on 2009/12/09 05:12:59
I was surprised it was only in hard skill.
easy/159 normal/169 hard/175
So it seems hard skill has 6 entities over the limit.
 Single Player Mappers....
#284 posted by MadFox [84.26.170.230] on 2009/12/09 05:15:38
and yes, the map is rather full.
925 entities, 263 lights, 26288 faces.
 Madfox:
#285 posted by metlslime [64.175.155.252] on 2009/12/09 05:40:23
to give more explanation, the "Signon Buffer" is basically a snapshot of the initial map state, which includes the initial state of all edicts, plus any static entities in the level. So you could reduce it by reducing edicts or by reducing static entities.
 Reducing Signon Tips
#286 posted by Preach [94.192.82.29] on 2009/12/09 11:39:21
The signon buffer has to detail every entity which spawns with a model set. One of the ways you can reduce the size of the buffer content is to have some entities set their models a few frames after the server starts.
It is possible to do this with a hack that works in virtually any quake mod that contains a func_wall and an info_notnull, but it relies on you having some func_walls to apply this to. Take one of these existing func_wall entities, and change it's classname to info_notnull(without making it a point entity). Then add the following keys:
"nextthink" "0.5"
"think" "func_wall"
This will make the func_wall spawn 0.5 seconds after the server starts, which removes it from the signon buffer. Instead it gets sent as one of the first update packets. You need to be careful picking a func_wall to use for this trick. If some other entity will spawn on the wall or may move into it before it spawns, then this trick will probably trap that entity inside the wall. So be a little careful.
This trick cannot be used on any entity which requires a precache, which limits it a great deal. Brush entities have the advantage of getting their model precached automatically. A silent func_plat is possible, although those will give you warnings about sounds, so not a good idea. A func_illusionary will not work, as they are made into static entities which must be in the signon buffer for players to see them.
Incidentally, this trick can be easily adapted to make func_walls spawn in levels when triggered. Take the info_notnull wall, and instead of think/nextthink, add "use" "func_wall" and give it a targetname. Just be careful about entities getting trapped inside...
 Fitzquake-SDL On ARM?
#287 posted by Jago [194.86.38.38] on 2009/12/09 14:25:28
Is Fitzquake-SDL likely to run on an ARM-based device (Nokia N900) running Debian Linux, assuming the required libs are present?
 No Idea
#288 posted by SleepwalkR [85.179.27.243] on 2009/12/09 18:48:17
It would have to be recompiled for ARM, that's for sure. AFAIK, SDL can be compiled for ARM, so there's no problem there. What about GL support on that platform? I'm not sure, but I doubt that OpenGL ES is enough to run Fitz.
 OpenGL Support
#289 posted by Jago [84.249.95.211] on 2009/12/09 19:52:51
Considering that even much "lesser" phones like N95 and even N80 could run accelerated GLQuake and Quake2, I would be surprised if this wasn't the case for N900.
 OpenGL ES
#290 posted by Jago [84.249.95.211] on 2009/12/09 19:55:41
It seems that Nokia N95 has OpenGL ES 1.1 while the N900 ships with ES 2.0.
 Jago
#291 posted by JPL [82.234.167.238] on 2009/12/09 20:02:38
#290 should have been posted in Phone Thread :P
 Thanks
#292 posted by MadFox [84.26.170.230] on 2009/12/09 21:09:58
for the explanation.
I changed six func_wall ents but for some reason the signon buffer keeps alerting.
Think I delete some entities as it seems the most simple solution.
 64-bits?
#293 posted by Lardarse [62.31.162.25] on 2009/12/12 08:55:58
Talking to a friend about playing Quake on Linux
fitzquake has horrible issues with x86_64
namely using unsigneds to store pointers, VERY BAD PRACTICE
Thought whoever is going to be working on the next version might want to know about this...
 Lardarse...
#294 posted by metlslime [98.248.107.212] on 2009/12/14 01:51:37
yeah, pointers are treated as 32-bit in various places. Maybe if 64-bit becomes important, I'll figure out what is needed to fix it.
 Huh
#295 posted by grahf [76.104.21.196] on 2009/12/15 03:56:41
Since when did quake need to address more than 4 gigabytes of memory?
 Rotating Brush Support
#296 posted by Baker [99.54.146.62] on 2010/01/18 14:28:33
For the sake of keeping FitzQuake 0.85 stuff where it can easily be found:
FitzQuake085_rotate.exe (with source)
http://www.quake-1.com/docs/rotate...
Sample rotating object map (rotate.bsp and rotate.map compiled with LordHavoc's new version of hmap2)
http://www.quake-1.com/docs/rotate...
Rotation support (avelocity) added from this tutorial:
http://www.quake-1.com/docs/quakes...
YouTube video of spinning object in DarkPlaces, appears to work and look the same in FitzQuake085_rotate.exe:
http://www.youtube.com/watch?v=Bke...
#297 posted by Willem [24.199.192.130] on 2010/01/18 14:35:13
What the hell is going on in that video? :) I can't tell what's rotating ... the player? But why is the room turning ... I .. ARGH!!
 It Looks Like
#298 posted by grahf [76.104.21.196] on 2010/01/18 21:29:02
the player is not rotating, but the thing he's standing on is.
How is this different, in technical setup and/or mapper use, than Hipnotic's rotating stuff?
Could be a big boon if the texturing of these rotators is more sane.
#299 posted by gb [89.27.229.197] on 2010/01/18 21:32:27
no func_movewalls
 Cool...
#300 posted by metlslime [173.11.92.50] on 2010/01/18 23:13:03
I've been following the thread on i3D as you guys discussed this. The remaining things I think would be ideal:
- engine: rotate player orientation as the object they are standing on rotates.
- compiler: origin brush support for ease of use
- compiler: fixed texture alignment on rotating models (right now it's all wrong because the brushes are moved to the world origin during the compile process without locking the textures)
Also I believe the way collision is being done for this is not correct, rotating the collision hulls can have some pretty non-optimal results, especially if you rotate a bmodel onto its side, since player bounding boxes are taller than they are wide. But doing it correctly would be pretty hard. I think what quake2/3 do is, save the original brushes in the bsp file and expand them to collide as needed, and don't use hulls at all.
 Rotating Doors
#301 posted by Baker [99.54.146.62] on 2010/01/19 01:04:16
Although there are many theoretical things that can be done with rotation and known issues with it in Quake, I only care about rotating doors. ;)
Maybe draw bridges that rotate down too.
Hip rotate doors kill me and otherwise are all weird. And if map authors want spinning things for show and level atmosphere, they can always put some clip around them ... to my knowledge the hiprotate objects have the same problems but at least these are FAR easier to setup.
 Different Problems
#302 posted by Preach [94.169.109.218] on 2010/01/19 01:14:49
The hiprotation objects have some problems, but they are consistent - the movewalls themselves don't rotate, so they don't start colliding with the player differently depending on the rotation it takes. Score one for hipnotic I guess...
 Avirox Rotation Version 1
#303 posted by Baker [99.54.146.62] on 2010/01/19 03:53:10
http://www.quake-1.com/docs/rotate...
Rockets and grenades appear to collide properly. ;)
 Yeah...
#304 posted by metlslime [64.175.155.252] on 2010/01/19 05:43:54
point-size entities will behave correctly, since a rotated point is still point-sized. It's hull1 and hull2 which are built around box-shaped entities which will exhibit inaccurate collision when the hull is rotated.
#305 posted by gb [89.27.245.204] on 2010/01/19 14:14:40
I believe for legacy maps, and people who simply want to keep using them, hiprotate will not go away... Quoth supports it nicely, RMQ will keep supporting it as part of its backwards compatibility effort etc...
For those of us who would like to do it in a more sane way in the future, the avelocity based rotation will be a gift of the gods.
Meaning, with RMQ and other forwards-compatible mods, you'll be able to have what you prefer.
 Metl
#306 posted by spy [92.46.17.254] on 2010/02/08 14:04:29
what does it mean:
it's from a console log
-------------
]quit
VID_Gamma_Restore: failed on SetDeviceGammaRamp
-------------
 It Means
#307 posted by Spirit [80.171.1.110] on 2010/02/08 14:35:29
ATI sucks.
 Spirit
#308 posted by spy [92.46.17.254] on 2010/02/08 14:52:19
i got nvidia
 Damn
#309 posted by Spirit [80.171.1.110] on 2010/02/08 15:05:01
Well, I think it says something about not being able to restore the original gamma (of the OS versus the one ingame).
 Spy:
#310 posted by metlslime [173.11.92.50] on 2010/02/08 22:41:46
it means restoring your desktop gamma setting didn't work, but i'm not sure why -- windows doesn't give any useful error messages when that happens.
 Windows Is A Piece Of Shit
#311 posted by ijed [190.20.73.47] on 2010/02/09 04:35:29
That's what it means.
A piece of shit geared towards your needs, the users needs.
I can't be arsed - but imagine I'd just gone on for a while about how magical a piece of shit can be, but at the end of the day is still something that won't fuck off no matter how many times you flush.
 Oh...
#312 posted by metlslime [173.11.92.50] on 2010/02/09 04:46:13
also, after talking to somebody by email (baker, jpl, or spirit, or maybe someone else)... that person told me he was getting the message even int cases where the gamma change actually worked! So sometimes the "failure" isn't actually a failure, from that one user's report.
 Error Code 23
#313 posted by Spirit [213.39.219.63] on 2010/02/09 09:19:48
Post failed!
 Crucified Zombies Do Not Work.
#314 posted by Ron [86.80.123.127] on 2010/02/22 18:02:03
They fall true the map.
In all the other engines they hang on the wall, but in Fitz ver .85 they either appear normal, throwing meat at you, or they fall true the map.
I don't get it.
If I start the start.bsp map, they are all hanging nicely on the wall, but in my own (nearly done) map, they don't.
 Sorry, Spoke Too Soon. Again ...
#315 posted by Ron [86.80.123.127] on 2010/02/22 18:12:36
Can't delete my previous post.
There was something wrong, but it was because I was using an alternative pack.
Sorry ...
#316 posted by [194.65.24.228] on 2010/02/24 10:57:40
fitz0.85 is opengl right?
still dont understand what fitzquake have that joequake,qrack,glquake e.t.c dont have because with my ATI X850 in the only that dont screw my image...
:( but i whould love to know what it is :| need joequake to record speedruns demos :(
 194.65.24.228
#317 posted by Mr Fribbles [118.209.221.29] on 2010/02/24 11:19:12
gl_ztrick 0
#318 posted by Trinca [194.65.24.228] on 2010/02/24 11:23:23
Mr Fribbles are you joking or serious?
I dont understand nothing about those things... if true i will try when i get home
thanks!
if joequake have this command...
 Mr Fribbles
#319 posted by Trinca [194.65.24.228] on 2010/02/24 13:03:23
gl_ztrick i google it, and i guess you are right... zomggg will be the first thing I will do when I get home...
 Yeah
#320 posted by nitin [124.168.7.215] on 2010/02/24 13:22:10
I think fitz sets ztrick to 0 by default.
 "gl_ztrick"
#321 posted by spy [95.56.57.207] on 2010/02/24 14:39:51
there is no such command in fitzquake0.85
#322 posted by trinca [85.139.229.53] on 2010/02/24 20:38:55
finaly got home and try!
FUCKING YEEEEEEEEEEEEEEEEEE
is working
/me kisses Mr Fribbles
 Yeah...
#323 posted by metlslime [173.11.92.50] on 2010/02/24 23:21:50
I removed ztrick long ago. It was basically a hack to avoid clearing the z-buffer between frames, at the cost of half the z-buffer precision. It didn't play well with my sky rendering code, plus it's not needed any any card newer than the voodoo1.
 MP3 In Fitz0.85
#324 posted by onetruepurple [89.75.203.25] on 2010/03/06 15:59:36
I'm using the fitzquake085_mp3 build supplied in Baker's mp3 support tutorial but I can't get it to actually play any mp3 files. :(
I have no idea what could be possibly wrong. My soundtrack is in id1\music (or travail\music for that matter), and not within a .pak either. The playback related console messages appear for me, and I can use the mp3 commands just fine (without any errors that is). Nothing plays, still.
Is it as simple as turning it on with a cvar, or something?
 Travail Music
#325 posted by Baker [99.54.144.122] on 2010/03/06 17:14:27
You have to use these mp3s due to the file names:
http://www.quake-1.com/files/modfi...
They go in id1\music or travail\music folder.
 Um
#326 posted by onetruepurple [89.75.203.25] on 2010/03/06 17:49:20
I have already renamed the mp3's myself beforehand. I also have the original Quake soundtrack in id1\music, also named track##.mp3.
 On Start Map
#327 posted by Baker [99.54.144.122] on 2010/03/06 18:25:15
If it says ...
"track name is 03"
"playing track03.mp3"
Then check the volume control in Windows.
If it is just saying ...
"track name is 03"
and doesn't say "playing track03.mp3"
Then you don't have track03.mp3
If you aren't using -nocdaudio and aren't getting either of the above messages, something else is wrong.
#328 posted by onetruepurple [89.75.203.25] on 2010/03/06 18:37:11
It says:
Track name is 03
playing track03.mp3
It's not my sound being disabled from within Windows, either, I can listen to anything else just fine.
 Stupid Test
#329 posted by ijed [190.20.89.221] on 2010/03/06 18:56:37
Have you tried renaming any old map and replacing one?
#330 posted by onetruepurple [89.75.203.25] on 2010/03/06 19:01:31
After testing several maps from several gamedirs, I can safely say it's not a mapside problem ;)
 ..
#331 posted by Baker [99.54.144.122] on 2010/03/06 19:12:37
If it says playing, you can rule out everything the user is doing as a problem. It isn't the map or anything else.
It's either the engine, DirectX drivers or possibly Windows settings somehow.
In the future, I'll get broader testing of the change to get wider feedback. This modification hasn't had broad testing at this point.
 Dear Fitzquake
#332 posted by gb [89.27.240.16] on 2010/03/07 01:24:18
These are some features I think any Quake engine should have these days:
1. connect blah:port working well (this is the game that introduced online multiplayer after all)
2. NAT fix
3. Ping in scoreboard (it's just useful)
4. Support for fake CD tracks from ogg or mp3 files
The reason for having the basic multiplayer functions is that some people test their multiplayer-capable mods in Fitzquake because they're doing singleplayer maps as well.
The reason for the ogg/mp3 support (ogg is fine) is that finding and swapping and maintaining and storing CDs is a nightmare, especially since Quake CDs are getting older and rarer, and the Steam version doesn't come with the CD.
 Ug
#333 posted by ijed [190.20.88.90] on 2010/03/07 02:16:03
My stupid test suggestion was made stupider. I meant to say 'mp3' not 'map'.
 Also
#334 posted by ijed [190.20.88.90] on 2010/03/07 02:22:54
An SP engine feature request / question.
Could we have global sounds play genuinely globally, and not only when in the player's LOS?
#335 posted by gb [89.27.240.16] on 2010/03/07 04:46:55
Yeah, that should go into QSB 1.0.
Sorry for thread hijacking :-P
 Condebug Lag
#336 posted by negke [88.70.58.238] on 2010/03/09 13:12:31
Unlike other ports, Fitzquake freezes for a couple of seconds when using the edicts command in conjunction with -condebug.
 Interesting... I'll Have To Check That Out.
#337 posted by metlslime [173.11.92.50] on 2010/03/09 23:27:25
 Edicts Command With -condebug
#338 posted by mh [78.152.225.32] on 2010/03/20 02:07:05
That actually sounds normal enough. The edicts command spews a *lot* of text to the console, all of which is written to the HD using unbuffered IO when -condebug is enabled. I'd be surprised if an engine does anything other than freeze for a short while, in fact.
 Yeah...
#339 posted by metlslime [173.11.92.50] on 2010/03/20 05:06:06
the solution is to buffer that stuff, but the negative of buffering is if you crash before you flush the buffer, you end up not logging whatever was buffered.
I guess it depends on what the primary use case of -condebug is. If it's diagnosing a crash, vs. just a convenient reference for later use.
#340 posted by negke [88.70.60.245] on 2010/03/20 10:25:16
Well, it works flawlessly in GLquake and Ezquake for example. Winquake freezes, too.
The delay varies depending on the OS. On XP, it takes roughly 40 seconds for E1M1, on Win7 almost 100 seconds (and I even had to close it from the task manager afterwards). GL seems to handle the buffering differently then?
 Necros:
#341 posted by metlslime [67.188.81.46] on 2010/03/20 21:26:37
ah, good to know. I can look at how they do it, maybe i did break something.
#342 posted by mh [109.79.207.208] on 2010/03/22 19:38:57
> Well, it works flawlessly in GLquake and Ezquake for example. Winquake freezes, too.
That's odd because it's the same code in WinQuake as in GLQuake...
#343 posted by stevenaaus [60.240.198.243] on 2010/03/22 21:12:07
On my linux C2D box, there's a noticeable delay, but nothing really. Day of the lords with 144/166 kills takes less than 2 secs with -condebug. Whatever it is, i think it's in quore-0.3.0 too, which uses some fitzquake code.
#344 posted by Spirit [213.39.169.214] on 2010/03/22 21:33:06
1s here (athlon 2 x2 240). Exe: 16:04:11 Jul 5 2008 on Lunix.
 One Difference...
#345 posted by metlslime [173.11.92.50] on 2010/03/22 22:05:56
The original glquake generally would redraw the screen once for every line of text printed to console. For large dumps (like the edicts command) this took a long time, so I changed it to write everything first, then update the screen once at the end.
This is faster overall, but results in a small period of no screen redraws. Since in my testing it only takes a fraction of a second, I never saw this as being a problem. I suppose that with -condebug, it takes longer and this hang is noticable. However, the alternative is that printing 500 lines takes 500 render frames, i.e. like 5+ seconds.
I still haven't tested this so it may be there is some other dumb bug causing the lag. But that's my current theory.
#346 posted by necros [99.227.131.204] on 2010/03/22 23:01:07
i guess there's some coding reason why you couldn't just make it print 100 characters at a time instead of all or nothing?
#347 posted by metlslime [173.11.92.50] on 2010/03/22 23:48:49
probably the whole system needs to be re-thought. Quake has some weird linkage between console updates and screen renders which doesn't make a lot of sense; I think the original motivation was when you are disconnected there is no map rendering to trigger a screen redraw, so the console printing needs to do it.
Really we should just redraw the console at a fixed rate when disconnected, and then printing doesn't have to be linked to drawing.
 Reasons For -condebug
#348 posted by mh [109.79.196.232] on 2010/03/23 01:24:56
I'm just curious as to the reasons why someone would want -condebug on all of the time. I suspect that it's not intended for this kind of general use (the presence of "debug" in the name kind of gives that away...) so it shouldn't really be considered performance-critical.
Seems to me that people might be using it to keep a log of events in a multiplayer game rather than it's intended purpose (checking console messages immediately prior to a crash - see the Quake readme) so maybe switching it to buffered I/O as a default is the way to go.
I'd suggest adding a "condebug" cvar, so it can be toggled if it causes trouble. Value 1 uses buffered I/O, value 2 uses unbuffered I/O. Also use unbuffered I/O if developer is 1. You can keep -condebug on the command-line, check it at startup and set the appropriate cvar value if you wanted as well.
 I Forgot To Add...
#349 posted by mh [109.79.196.232] on 2010/03/23 01:37:24
...that the edicts command is a pathological worst-use-case as well. Expecting performance from it might be a little bit unreasonable.
And also that it's actually quite important for the intended use of condebug that it be unbuffered and write each line individually, otherwise you might not get the console message indicating what caused the crash.
 Mh
#350 posted by Mr Fribbles [59.167.199.179] on 2010/03/23 03:04:26
I'm just curious as to the reasons why someone would want -condebug on all of the time.
Multiplayer stats. Sometimes people want to log all the console output, and use an app/script to parse the logs for death messages or whatever (to generate a breakdown of kills, deaths etc).
Just one scenario where you may want it enabled all the time.
#351 posted by stevenaaus [60.240.198.243] on 2010/03/23 08:55:56
Non trivial disk accesses are best left to the OS anyway.
One way with linux is "fitzquake | tee FILENAME", which duplicates stdout to a file. Neg_=!ke's worst case was with Win7 too.. which may still have the occassional disk performance issue, ala vista. Just out of curiousity, Negke - in win7, shut down everything which uses sound, run fitzquake with -nosound, and see if there's any improvement.
Still, 40 seconds on XP indicates there is a problem. Hmmm... I just tried a 170 enemy map by tronyn. Linux - 2 secs, XP - 7 secs. Perhaps it's the crappy vfat filesystem, which performs really bad when it's getting full ?
#352 posted by negke [88.70.232.83] on 2010/03/23 09:31:56
I don't have it enabled all the time. It's only to get a copy of the edicts list - when looking for modelindex values, for example. The condump command often doesn't help here because of the console text limit.
stevenaaus: still freezing with -nosound, too.
#353 posted by mh [78.152.224.183] on 2010/03/23 19:25:11
> Multiplayer stats. Sometimes people want to log all the console output, and use an app/script to parse the logs for death messages or whatever (to generate a breakdown of kills, deaths etc).
That's what I kinda suspected, and supports the case for changing it to buffered by default.
#354 posted by stevenaaus [60.240.198.243] on 2010/03/24 09:39:59
Holy cow - by "unbuffered" i didn't realise we're performing a file-system open and close on every line written to console! No wonder there's problems. Hmmm... but tyrquake does it too, and i suppose others.
Anyway, i ran strace on quakespasm and tyr-glquake with
strace -ologtyr ./tyr-glquake -condebug +timedemo demo1
strace -ologqs ./quakespasm -condebug +timedemo demo1
which records all system calls.
Playing the demo, qs makes 666 (!) calls to "open", and tyr-glquake 218.
qs opens every file in the "quake" directory (probably checking for mods), which accounts for 83 "opens" on my box, but there's also a heap of qs-only opens which i think are related to the texture manager, and look like this
open("./id1/textures/cop3_4.t... O_RDONLY) = -1 ENOENT (No such file or directory)
open("./id1/textures/e1m3/wsw... O_RDONLY) = -1 ENOENT (No such file or directory)
(except the forum is inserting some "..." here)
I guess it's something to do with the fitzquake texture manager, perhaps using a file system open ?? I've never played with strace before, so i could be mistaken about something too.
#355 posted by Spirit [213.39.223.254] on 2010/03/24 10:25:48
I guess the extensions are .tga and maybe .jpg? Fitzquake probably checks if replacement textures exist for each texture in the current map load. I have no idea but maybe one could change that to something that does not try open right away but simply pings for an existing file?
 -oh-yeah
#356 posted by stevenaaus [60.240.198.243] on 2010/03/24 11:14:18
About how fitz dies on win 7, perhaps the delay is so long it's causing a server timeout or buffer overflow of some sort.
 It Only Died Once
#357 posted by negke [88.70.250.187] on 2010/03/24 11:52:54
I just tried it again and could continue/quit normally after the delay.
#358 posted by stevenaaus [60.240.198.243] on 2010/03/24 14:46:25
I'm not sure it means anything actually. There's certainly a lot of extra "open" system calls - in the travail demo1 it's 275 for tyr and 1053 for qs and bakers fitzquake-sdl. But looking at ~when~ they're occurring, afaics they don't seem to overlap the repeated open and closes of qconsole.log.
 Open Calls
#359 posted by mh [109.79.192.79] on 2010/03/24 19:51:14
External textures need an open and close call to load, so that's probably it. Especially as I doubt TyrQuake supports external textures. The number of open calls is quite likely misleading here, as each open call isn't necessariy a success, and one that fails won't be leading to any consequent IO. Measuring the number of close calls would give you a better yardstick.
A possibly better solution for the condebug thing would be to buffer the text into main memory instead and only write it to disk when the memory buffer fills. Even a 1 KB memory buffer would remove a lot of the pain.
Still need to keep an unbuffered version for crash diagnostics though, and I say run with my suggestion of the cvar and "condebug 2" for that.
 Update...
#360 posted by mh [109.79.192.79] on 2010/03/24 20:16:36
Yup, that works. :)
We're down from a lockup of up to 10 seconds to almost instantaneous.
I use a buffer size of MAXPRINTMSG and copy text into that instead of writing immediately to file. When a new update would overflow the buffer I write to file then, and reset it.
When disconnected from a server everything gets written to file immediately. This handles the final necessary buffer flush when shutting down, and I reckon it's not so performance critical anyway.
condebug 2 or developer 1 will force the writing into no memory buffer and unbuffered IO mode.
 Its_a
#361 posted by stevenaaus [60.240.198.243] on 2010/03/25 10:22:02
bit of a storm in a teacup anyway, laugh.
Buffering sounds feasible... but a little overcomplicated with condebug and condebug2 or whatever, because using buffered output will screw up with a program crash. Code ?
Would using windows redirection commands suffice... or is there an fsync for win32 ?
#362 posted by mh [137.191.242.106] on 2010/03/25 14:14:38
It depends on what condebug is used for. If it's only used for crash diagnostics then it's perfectly fine to change nothing. But if it's going to be used for general-purpose logging of multiplayer games then obviously something more needs to be done. In any event the default behaviour should be what people expect it to be, and if people are complaining about stalls with it, then that's obviously not the case.
Does anyone even use it for crash diagnostics any more?
I don't think that creating a condebug cvar with values of 1 or 2 is necessarily a complicated thing. Certainly no more complicated than all the crap that you had to do to get WinQuake working on an old SVGA card for example.
Oh, and code: http://directq.codeplex.com/releas... (all in console.cpp)
#363 posted by stevenaaus [60.240.198.243] on 2010/03/26 13:30:28
Mehhmmmm... It's a bit of futzing around, but looks ok. Are you flushing the buffer when Sys_Quit ?
#364 posted by mh [109.79.179.20] on 2010/03/27 02:42:25
No need to cos it flushes anyway when cls.state != ca_connected which will be true during a Sys_Quit.
#365 posted by necros [99.227.131.204] on 2010/03/30 09:45:05
having some odd problems with fq085 in windows 7.
host_maxfps is set at 72, but the game runs too fast. i tried lowering maxfps to 60 and even 10, but the game plays at the same (too fast) rate.
my desktop res is 1600x1200x32 so i run the game at that as well. tried both fullscreen and windowed.
the game runs without compatibility mode, but i tried xp sp2 and sp3 mode but it didn't make a difference.
the exact command line is:
fitzquake085 -heapsize 192000 -particles 20000 -nocdaudio -width 1600 -height 1200 +gl_clear 1 +scr_conspeed 32768 -bpp 32 +developer 1
 Necros:
#366 posted by metlslime [67.188.81.46] on 2010/03/30 10:19:52
is it multicore? Apparently there's a clock bug in quake (including fitzquake) which screws up the timer if the process switches cores (since the different cores have different clock speeds sometimes? not sure exactly.)
Some engines claim to fix this, including DirectQ and Proquake, though they seem to have different approaches to fixing it.
#367 posted by necros [99.227.131.204] on 2010/03/30 10:31:49
weird, i never had the problem in winxp even though i had a multicore processor back then.
the win7 i'm using is 64bit though, and my copy of winxp is 32bit..?
am i SoL for fitzquake then? o.o
 Necros:
#368 posted by metlslime [67.188.81.46] on 2010/03/30 11:17:14
well i'm not sure, here is the info i have found about it (assuming it's actually the problem you're experiencing):
http://mhquake.blogspot.com/2009/1...
Here's a possible workaround:
http://quakeone.com/forums/quake-h...
Another possible workaround is to tweak host_timescale to try to get the time back to normal (or at least close) ...
 Necros:
#369 posted by metlslime [67.188.81.46] on 2010/03/30 11:25:32
also Quakespasm is based on fitz 085 and might have this fixed (it uses SDL, which has its own clock code i think...)
#370 posted by mh [109.79.233.28] on 2010/03/30 19:48:44
Brief description of the problem here: http://www.informit.com/guides/con...
The relevant part is: "What QueryPerformanceCounter doesn’t understand, we’re finding out, is multi-core processors. On an Athlon64 X2 processor, QueryPerformanceCounter will sometimes report negative elapsed time, for reasons that are as yet unclear. One theory was that the timing code was being shuttled between the processor cores and that the cores’ time bases weren’t always in sync. That might indeed be the problem, but just setting the timer thread’s affinity to a single core doesn’t appear to be the solution.".
Also more here: http://www.virtualdub.org/blog/piv...
Using timeBeginPeriod and timeGetTime seems to be the way. You can test if these avoid the issues by running QuakeWorld, Quake II or Q3A on the same system: all of these use timeGetTime instead.
#371 posted by mh [109.79.233.28] on 2010/03/30 19:53:51
Another good one here: http://jongampark.wordpress.com/20...
"The 1st glitch is that the returned value easily exceeds the boundary of the 64bits for the QuadPart, because current CPUs are so fast."
DirectQ's implementation by the way keeps the returned value from timeGetTime as a DWORD for as long as possible, using that in all calculations and comparisons, and only converting to float when absolutely necessary.
#372 posted by necros [99.227.131.204] on 2010/03/30 20:48:18
that definitely sounds like the problem, and i can confirm that just setting cpu affinity doesn't do anything.
i think the problem might have more to do with 64vs32 bit rather than dual core though, since as i mentioned, the problem was non-existent on a winxp 32bit system with the same cpu (core2duo 6300).
#373 posted by necros [99.227.131.204] on 2010/03/31 04:21:02
i nabbed direct fitzquake, but it still has that timing problem, so i tried out directq, which does not. (quake3 didn't have the problem either, but the sound stuttered, including ioquake3)
 Triple Posting, Sorry
#374 posted by necros [99.227.131.204] on 2010/03/31 09:33:14
just wanted to also mention that quakespasm also was fine, so both directq and quakespasm are alternatives if you get the timing problem.
#375 posted by mh [78.152.238.140] on 2010/03/31 12:21:26
Definitely QueryPerformanceFrequency and QueryPerformanceCounter then. I guess the SDL guys are well aware of the issues with them and used alternate approaches in the SDL timer.
Ironically the reason I did this in DirectQ was *not* to resolve the timer issue, but to deal with a completely separate matter (D3D manipulating the FPU control word).
 Metlslime
#376 posted by sock [88.110.143.38] on 2010/04/02 02:32:11
Thanks man, your engine worked perfectly for me and it made playing Q1 a pleasure again. Thanks for all the hardwork on this, awesome work :)
 Sock:
#377 posted by metlslime [67.188.81.46] on 2010/04/02 10:03:36
glad to be of service :)
as you can see above, i still have some work to do :|
 Metl
#378 posted by spy [95.56.9.62] on 2010/04/08 18:05:58
i ran some mod via fitz085 and sometimes 'SV_TouchLinks: next != l->next' message popups
what is it? , i know this is somehow related to a teleporter,
 The Mysterious Engine Killing Teleporter
#379 posted by mh [137.191.242.106] on 2010/04/08 18:26:36
#380 posted by negke [88.70.57.11] on 2010/04/08 19:11:27
I saw that message, too, a couple of times and wondered what it means. For apparently, it's not THE sv_touchlinks issue, the one that crashes unprepared engines (like in E2M2). Check the pent secret in my coag map for reference.
 Spy:
#381 posted by metlslime [173.11.92.50] on 2010/04/08 21:48:11
it's a fix for what mh linked to.
However this fix ended up being a problem because it crashes White Room, so i need to figure out how to fix it correctly for my next release.
#382 posted by mh [109.79.134.60] on 2010/04/08 21:59:00
My implementation of the more robust fix is here: http://forums.inside3d.com/viewtop...
Works with both proxmap2 and whiteroom.
#383 posted by negke [88.70.65.141] on 2010/04/08 22:22:32
Seems like the issue doesn't always necessarily lead to a crash/freeze then.
#384 posted by mh [109.79.134.60] on 2010/04/08 23:58:01
Depends on the QC. Apparently calling remove while touching links is what can cause the lock-up, but no doubt it's possible to construct QC that does other lesser but still nasty things.
 Remove
#385 posted by Preach [94.171.242.186] on 2010/04/09 01:13:56
It seems like quite a dangerous restriction on the qc, because a lot of the time you're writing code for which you have no idea if it's going to be run in a touch function or something safe like a think function instead. For example, a death function might get called from a collision or a hitscan attack originating from playerpostthink.
Still, it's nice to think that the original QC authors have made sure to take this instruction to heart. They would never call remove directly within a function used as a touch function, Especially not one as common and clearly labelled as spike_touch
Oh, wait...
In conclusion, I'd guess that removing one of the entities involved in the collision is generally safe, and it's when you start removing 3rd party entities that the problems arise. Can anyone who understands the e2m2 crash better than me confirm or deny that? And would making sure killtarget uses SUB_Remove on a short-delay think fix that case?
#386 posted by mh [109.79.202.173] on 2010/04/09 02:52:41
I'm not certain that I'd see it as a restriction on QC, but more a case of QC authors either not knowing their tool or not testing well enough. It's possible to write software that crashes in any language, and QC should be no exception. If writing in C for example I'd conform to the rules of the language, and not expect something I write to always work just because I wanted it to.
If it breaks in ID Quake then by definition it's broken is my opinion, and this one breaks in ID Quake.
I think the short-delay think sounds like a good idea, but my own QC knowledge is quite limited.
 Challenge
#387 posted by Preach [94.171.242.186] on 2010/04/09 10:24:37
What I'm saying is that it's virtually impossible to write QC which guarantees it doesn't remove things during touches - calling that a case of QC authors either not knowing their tool or not testing well enough. is disingenuous. A mapper could potentially apply any function in the progs as a touch function to an entity, including SUB_Remove.
Even if you argue that this one is the mapper's fault, that's just the least subtle problem. When I cited the example of a death function which could be called from both touch and non-touch functions, the important thing to note is that the two cases are indistinguishable from the QC. There's no flag you can read, and you can't create one yourself because any function could be made into a touch somewhere.
If you were willing to compromise some responsiveness in removing entities and guessed at the most likely circumstances, you could probably reduce the amount of "remove during touch" by 90% compared to the original progs. But totally preventing it on the qc side isn't just a case of a little bit of care - it's so hard I don't even know if it's possible.
 Timing Issues
#388 posted by R00k [66.64.112.129] on 2010/04/12 20:54:23
Here's what's used in quakeworld clients like Zquake, that I've used in Qrack with 64bit windows 7 without any problems.
/*
================
Sys_InitDoubleTime
================
*/
void Sys_InitDoubleTime (void)
{
timeBeginPeriod (1);
}
/*
================
Sys_DoubleTime
================
*/
double Sys_DoubleTime (void)
{
static DWORD starttime;
static qboolean first = true;
DWORD now;
now = timeGetTime();
if (first)
{
first = false;
starttime = now;
return 0.0;
}
if (now < starttime) // Wrapped?
return (now / 1000.0) + (LONG_MAX - starttime / 1000.0);
if (now - starttime == 0)
return 0.0;
return (now - starttime) / 1000.0;
}
Hope this doesnt reitterate what someone else said as I didnt read the whole thread :P
 /\
#389 posted by necros [99.227.131.204] on 2010/04/12 21:44:37
i think it's great to raise awareness of this issue as more of us pick up dual (or more) core processors and 64 bit operating systems.
 Cheat Commands..
#390 posted by rj [86.0.165.149] on 2010/05/20 18:14:34
regarding this feature from the readme:
- god, noclip, notarget, and fly can now be explicitly set. example: "god 0" will disable god mode
how possible would it be to make cheats, specifically notarget, be enableable from the command line? ie, by adding +notarget 1 to the end of your batch file or whatever so the map loads with it turned on... unless i am missing another way to do this?
 Rj:
#391 posted by metlslime [159.153.4.50] on 2010/05/20 19:28:09
have you tried it? It sounds like it would work.
 Alas
#392 posted by rj [86.0.165.149] on 2010/05/20 19:55:30
yes, and no..
 Rj:
#393 posted by metlslime [159.153.4.50] on 2010/05/20 19:58:56
try the different possible orders of command:
+map e1m1 +notarget
+notarget +map e1m1
I'm not sure which order things are executed from the command line, it might be reverse order. And since i think "notarget" etc. gets reset at map load, that might be the reason it doesn't always work.
#394 posted by rj [86.0.165.149] on 2010/05/20 20:31:50
And since i think "notarget" etc. gets reset at map load, that might be the reason it doesn't always work.
yeah that's what i figured. neither combination works (whether it has a '1' after it or not)
say i wanted to make it function like 'skill' - ie, carryable across maps, would that be qc-side or engine-side?
#395 posted by mh [109.79.187.222] on 2010/05/21 01:20:52
+notarget +map e1m1 works ok on WinQuake. Best way however to make something carry across maps is to use the changelevel command instead of map. Unfortunately changelevel needs an active server to carry over state from so it won't work on the command-line.
 Running Fitzquake
#396 posted by cubby4ever [24.121.32.39] on 2010/07/02 02:36:04
I need some help. When I try to run fitzquake it says it could not load gfx.wad I don't know what that is or what I should do does anyone know?
 Cubby:
#397 posted by metlslime [159.153.4.50] on 2010/07/02 03:38:24
are you trying to run fitzquake using a shortcut, or using a batch file? Or are you simply double-clicking on it directly?
 R_stereo 1 = Crash
#398 posted by Baker [99.54.147.35] on 2010/07/22 07:08:16
Looks like typing r_stereo 1 in the console in FitzQuake 0.85 causes a crash or some sort of infinite loop.
#399 posted by metlslime [159.153.4.50] on 2010/07/22 20:10:36
hmm, i thought that was fixed already... Or maybe the old bug was r_lightmap 1 + r_stereo 1.
Anyway, i'll look at it when i get a chance (crunching at work right now, so it might be a while.)
 Music Issue
#400 posted by Doriol [98.184.176.52] on 2010/08/07 21:43:55
Sorry if this as been answered already; I don't want to look through 400 posts.
How exactly are you supposed to get the music to work? I saw a link posted somewhere of fitzquake with MP3 support, but sadly the link is dead.
 Re: Music Issue
#401 posted by Doriol [98.184.176.52] on 2010/08/07 21:49:15
I would also like to add that I do have a physical copy of Quake I, purchased about 14 years ago (god I feel old). I read on the Steam forums that the music should play if you have the CD in the CD drive while you play, though I'm not sure if that applies to fitzquake. I also tried mounting it to the E drive with Daemon Tools.
#402 posted by Spirit [80.171.127.65] on 2010/08/07 22:36:03
It should play from the CD if you put it into the drive with the "highest" letter. So if you have 2 ROM drives F and G, you would put it into F. I am not sure if they need that ancient cd audio cable to the motherboard/soundcard or if those even exist anymore.
 Re: Music Issue
#403 posted by Doriol [98.184.176.52] on 2010/08/07 23:00:09
Whoops, my Daemon Tools virtual drive was D and Quake I was E. Going to disable the virtual drive and see if that fixes it. Thanks for the fast reply.
 Re: Music Issue
#404 posted by Doriol [98.184.176.52] on 2010/08/07 23:39:28
Yep, that solved it. Thanks.
 Re: Music Issue
#405 posted by Doriol [98.184.176.52] on 2010/08/08 03:46:39
Yay, another issue. The music doesn't loop. Has anyone else had this problem and/or have a solution?
I tried using fitzquake085_mp3.exe but I have the same problem as poster #326.
 Thanks Necros
#406 posted by Spirit [80.171.95.8] on 2010/08/08 20:58:31
profile during demo playback segfaults the engine.
#407 posted by Spirit [80.171.95.8] on 2010/08/08 21:21:49
wait, that was 0.80.
Quakespasm works.
 Also When Not Connected
#408 posted by negke [88.70.94.49] on 2010/08/08 21:21:58
What's the purpose of the command anyway?
 Re 406
#409 posted by necros [99.227.131.204] on 2010/08/08 22:20:05
thanks for?
profile dumps stats on which progs functions are being called the most. you can use it to see which functions are using up the most cpu time and take measures to either make them simpler (thus requiring less calculations) or make the functions get called less often.
#410 posted by necros [99.227.131.204] on 2010/08/08 22:21:51
#411 posted by Spirit [80.171.95.8] on 2010/08/08 22:43:08
thanks for making me try that command.
 Fitzquake Not Saving Config
#412 posted by Ether [90.198.186.155] on 2010/08/12 22:51:10
Good Day folks, pleasure to see Quake enthusiasts are still alive and kicking, even if the golden era of the mapping scene has long died away.
Simply put, upon modifying console cvars such as "scr_conalpha, r_lerpmodels, r_shadows" Fitzquake won't save this settings upon exit. I've tried setting 'Savedgamecfg' to '1' but to my frustration no effect. Any assistance would be appreciated.
Thank you!
 Gun Models Sit Below The HUD
#413 posted by Ether [90.198.186.155] on 2010/08/12 22:56:31
This bug has always befuddled me but in both conventional GLquake and Fitzquake the weapon models appear from below the HUD rather than sit above it. Needless to say, it looks awkward and I've seen a YT vid of GLQuake where this problem does not occur
 Ether
#414 posted by nitin [124.148.146.18] on 2010/08/13 01:39:30
just put them in autoexec.cfg
 Skin Trashed (ARWOP)
#415 posted by Baker [69.223.188.180] on 2010/08/24 16:30:17
I thought this was fixed in FitzQuake 0.85 versus FitzQuake 0.80 but somehow it happened:
http://quake-1.com/docs/any/arwop_...
Situation:
FitzQuake 0.85 on windows hosting a coop game in listen mode with maxplayers 2 playing ARWOP with other client being a QuakeSpasm client (not that I can see how that'd matter).
On ARWOP start map, other player's skin is fine but after advancing through changelevel teleporter to first ARWOP map, other player's skin is trashed.
#416 posted by necros [99.227.131.204] on 2010/08/24 21:47:22
is this the heapsize thing? i had a problem with the player skin getting mangled (along with other textures) and solved it by increasing heapsize.
but your question leads me to believe this isn't the same thing.
#417 posted by mh [109.79.251.221] on 2010/08/25 00:24:04
That looks more like a texture cache problem to me.
#418 posted by mh [109.79.251.221] on 2010/08/25 00:31:19
More info: Fitz's texmgr uses CRC to identify matching textures, but CRC is horribly prone to collisions. RSA have published some nice public domain MD5 code that I would generally recommend be used instead.
 5 Mousebutton Support
#419 posted by megalodonNL [85.146.84.169] on 2010/08/25 22:16:17
I'd love to see 5 Mousebutton support being added to FitzQuake so I can use it as my default SP engine.
 Ooo
#420 posted by necros [99.227.131.204] on 2010/08/25 23:28:03
yeah, this! ^^^
well, actually if all engines supported more than just mouse 1-3 that'd be awesome. :)
 Reason
#421 posted by megalodonNL [85.146.84.169] on 2010/08/26 00:04:13
The reason for 5 MB support is that I have +/-attack aliases for the weapons. As far as I know, all good players, like speedrunners, need to be able to fire the correct weapon instantly, without having to cycle through them to select and then using another button to fire. That is just stupid and you'll never get good in Quake that way, you only think you are.
It's painful enough that there's no 'bestweapon' support, which is supported by ProQuake, JoeQuake, DarkPlaces and QRack, but it feels even more handycapped when I can't at least use the extra mouse buttons to create some simple aliases.
Yes, I know that there's this little group of people here that is against everything that's different from how Quake was in '96 in terms of movement and weapon scripts, but I'm bringing it up once more because if FitzQuake would have these things, it can become much more popular in the SP scene and people like myself would actually be interested in playing all these great looking maps (from the screenies it looks great).
If you wanna be oldschool yourselves, fine. But at least let people have the choice for THE shooting-experience that sets Q1 apart from the sequels...and perhaps all other FPS games for that matter.
http://quakeone.com/forums/quake-h...
#422 posted by Spirit [80.171.95.102] on 2010/08/26 08:27:53
Bah, you don't need such binds for singleplayer unless you are a pussy. Just like FOV 90 (or the widescreen equivalent) is fine.
 Spirit
#423 posted by spy [95.56.197.36] on 2010/08/26 15:55:03
fov 90 is evil
#424 posted by rj [86.0.165.149] on 2010/08/26 18:11:40
Bah, you don't need such binds for singleplayer unless you are a pussy. Just like FOV 90 (or the widescreen equivalent) is fine.
bollocks on both counts
 Unless..
#425 posted by rj [86.0.165.149] on 2010/08/26 18:12:42
..that was sarcasm i failed to pick up in time. hrm
#426 posted by mh [109.79.209.11] on 2010/08/26 20:16:44
I actually think that in terms of features FitzQuake is pretty fine. Maybe it errs a little on the side of features for maps/mods while in development at the expense of features useful for actually playing the game, but that's understandable enough given the author's background, and overall there's nothing dramatically *wrong* with it (in terms of general features that is; I do think that there is some room for improvement elsewhere). A few nips and tucks in places is really all that it needs (let's have mouselooking enabled by default in the next version *please*).
#427 posted by metlslime [159.153.4.50] on 2010/08/27 00:57:31
I welcome these types of requests... if I haven't added a feature to fitzquake yet, it's usually because my to-do list is huge; not because I think the feature is a bad idea.
Also Baker: Thanks for the bug report; is it consistently repeatable? I'll see if i can track it down. It seems unlikely that it's a cache/crc problem (player skins are allocated specially) but it could be anything at this point.
 Rj
#428 posted by Spirit [80.171.95.102] on 2010/08/27 01:05:19
I am serious. I used a bind to fire grenades with a key for ages but it felt like cheating.
Also I played with FOV 120 for a long time (because I was like OMG I CAN SEE SO MUCH MORE AND IT FEELS FASTER TOO!!!1), then I realise that it was idiotic. So I gradually went down again. 110 for a while, then 90. Now I have a widescreen monitor where ~110 is like old 90 according to some list by LH.
 @Metl Re: Skin Issue
#429 posted by Baker [69.223.191.99] on 2010/08/27 12:41:53
I haven't tried to cause it to do it again, but I'll try to repeat the issue to verify it wasn't some one-time weirdness.
There is an outside chance it could have been caused by something silly like FitzQuake briefly losing focus during startup while video initialization was going.
@ Spirit
The reason "bestweapon" is "acceptable" to a Quake conversative is because the behavior is already attainable via other methods. It just reduces the number of keys you have to use and makes it so you don't have to write complex aliases.
So the effect of a bestweapon command is:
1. Reduce the number of keys you use
2. Reduce the complexity of binds
3. Make that kind of functionality available to non-experts in easier fashion.
It's kind of like impulse 10 and impulse 12, really. Of video mode switching. It doesn't offer anything new, it is just less of a pain.
#430 posted by Spirit [80.171.83.166] on 2010/08/27 13:07:08
I have nothing against people using it, I just think it is kinda lame. And potentially bad. If you eg have the SSG or SNG as "better" weapon than the SG/NG, then you are wasting ammo. How do people actually use it?
I am obviously talking about singleplayer.
 Binds
#431 posted by Baker [66.82.9.92] on 2010/08/28 04:08:20
I like using 3 keys:
1. One that switches the strongest non-explosive weapon. Lightning gun, SNG, etc.
2. One that throws a grenade and then switches me back to some safe weapon that won't kill me in close combat.
3. Something that switches to the rocket launcher or a fall back to the grenade launcher. To deal with clusters of enemies or zombies.
Pressing 1 through 8 is a bit slow and inconvenient. And impulse 10 and 12, while very useful and bound to my mousewheel, aren't always a good fit.
Not having those available just means I have to play more conservatively and save more often instead of playing more naturally.
I'm sure different ppl have different preferences.
 Well
#432 posted by megalodonNL [85.146.84.169] on 2010/08/30 20:33:16
Reading back through my last post it sound a bit harsh. I like to emphasize that Fitzquake is great and I'm thankful metlslime made it. It's just that I once read stuff about this 'bestweapon' subject and people where very nagative (and ignorant) about it.
So Spirit, since you are one of the ignorant people (heheh :P) I'm going to answer your question in this lengthy post:
The whole point is to have MORE then one weapon priority script for as many buttons as you'd like to use. I'm a QW player mostly, and I like to keep my SP config similar to my QW cfg.
I'll post some examples from my QW config. 'impulse' can be replaced by 'bestweapon' if you use Qrack or DarkPlaces:
alias +boomstick "impulse 2 1; +attack"
alias -boomstick "-attack"
bind MOUSE2 "+boomstick"
The above simply makes me instantly fire a long distance shot with MOUSE2. If I'm out of ammo, I hit with the axe, which makes no sense in this case. The boomstick is VERY precise and pesky long range weapon. With Quad, this is basicly the Railgun for Q1, which shouldn't be underestimated. In other words: you need a script and button for it so you can fire it instantly at any given time.
Next:
alias +rocketlauncher "impulse 7 5 3 4 2 1; +attack"
alias -rocketlauncher "-attack"
bind MOUSE1 "+rocketlauncher"
The above simply makes me instantly fire a rocket. If i'm out of rockets, I'll switch to the SNG and keep firing with that. Don't have nails? Then I instantly shoot with the SSG, etc. All by pressing just 1 single button. How cool is that?
But... what if an enemy is standing too close to me? I'd damage myself with the rocketlauncher... therefore:
alias +shaft "impulse 8 5 3 4 2; +attack"
alias -shaft "-attack"
bind SHIFT "+shaft"
The above simply makes me instantly use LG. Don't have it or don't have cells? I shoot with SNG, etc. All by pressing just 1 single button. This is my main button for close encounters. Why shift? Because when I don't put pressure on my mouse by holding down a mouse button, I can aim better with LG.
alias +supernailgun "impulse 5 4 3 2 1; +attack"
alias -supernailgun "-attack"
bind MOUSE5 "+supernailgun"
So I already had a button for close encounters, right? But what if I have LG and I'm in the water? I'd discharge myself. The best weapon underwater is the SNG... you can figure out the rest by now.
alias +supershotgun "impulse 3 5 2 1; +attack"
alias -supershotgun "-attack"
bind MOUSE4 "+supershotgun"
The SSG is awesome for close encounters, especially when you got no LG and even better when you got Quad (obviously) and want to take out most enemies with one single bang without damaging yourself.
THIS, ladies and gentlemen, is why you see these insanely good players change weapons so quickly and efficiently. It is superior to the old way.
Tere's one problem:
The only downside is when you play a SP mod that includes NEW weapons that sometimes replace standard weapons or toggle between standard and new. This can screw up some of the weapon scripts since a certain number will now stand for a different weapon that has a different function (long range instead close range, etc.).
A solution for that is either create a new .cfg or just change the MOUSE1 into the good old +attack and cycle through the weapons with mouse wheel or by pressing the 1-0 keys, which is very in-efficient but, I suppose, more realistic since in real life you also must take some time to switch weapons.
But then again: Quake isn't about realism because irl most ppl wouldn't survive jumps from great heights while losing only 5% of their 'well being' and you can't carry all these weapons either.
So I hope this clears up the big mystery about weapon scripts. It can be a lot of fun to experiment with them, including when you're playing against bots because bots can switch weapons REALLY fast.
I remember that, back in the day, the good old Reaper bots by Steven Polge gave me quite some problems. Nowadays, since I can switch just as fast as they can, I laugh about it and they are no threat to me at all. In QW I practice against Frogbot level 20 (highest) and I almost always win (1on1).
#433 posted by mwh [118.93.47.128] on 2010/09/05 03:28:59
I find I set up different binds for the keys around the wasd keys for different maps -- but then I am (or was, realistically) a speedrunner, so have a rather different outlook :-)
 Strange Mwh...
#434 posted by megalodonNL [85.146.84.169] on 2010/09/06 03:34:35
Seems to me that it's best to have the weapon binds organized in such a way that pressing them won't stop you from pressing movement keys at the same time... So having these weapon buttons around your movement keys doesn't sound smart for a speedrunner 'cause it will interfere with your movement.
Anyway, I've decided not to play (much) anymore, so I don't really care if the support gets added to Fitzquake.
 Those Scripts Show Well
#435 posted by megaman [91.66.119.75] on 2010/09/22 10:37:55
why instant weapon switching is not a good thing.
#436 posted by necros [99.227.131.204] on 2010/10/07 07:55:51
Z_Realloc: failed on allocation of 38912 bytes in quakespasm-20100821.exe
i know this is for fitzquake, but quakespasm is based on fitzquake.
happened in a mod and custom map. events that were going to occur as the crash happened:
a monster was about to spawn a new entity with a model that was precached but never used until that point.
it was also going to play a sound that was precached but never played till that point.
model was a standard quake model, but fairly large (maybe ~512 units across?) and used alpha settings.
sound was 44khz 16bit mono .wav file.
dunno if that's helpful. i was unable to reproduce the crash and have fought said monster many many many times before without ever crashing either.
#437 posted by stevenaaus [114.72.238.66] on 2010/10/07 12:37:46
Z_Realloc: failed on allocation of 38912 bytes
It appears you're hitting the Z memory limit for some reason. You can use "-zone 512" in your start-up script (default is 256k), or we could bump it in future versions whenever that is. If it's not reproducible...
#438 posted by necros [99.227.131.204] on 2010/10/07 19:01:20
what is z memory? is this specific to quakespasm?
 Zone Default
#439 posted by Baker [99.66.39.223] on 2010/10/07 19:49:52
On desktop operating systems there is really no reason to default the zone allocation in the engine to less than 1 MB.
1 MB provides compatibility with all mods.
I mean, the FitzQuake protocol uses a lot of memory itself and defaulting an extra 3/4 of MB for zone is nothing in comparison.
#440 posted by mh [137.191.242.106] on 2010/10/19 14:32:18
...not to mention that lightmaps require 16MB...
To be honest, scrimping and saving on zone memory in that kind of situation is like fretting over a pinhole in a leaky bucket when there's a great big gaping wide rent on the other side of it.
#441 posted by necros [99.227.131.204] on 2010/10/20 00:12:52
ok, so it's safe to just suggest to people playing my map to use, say, -zone 2048 just to be safe?
#442 posted by mh [109.79.219.140] on 2010/10/23 14:53:42
The zone memory system can be replaced outright by standard malloc/free, and doing so shifts the technical burden from the player (where it shouldn't belong) back to the developer (where it should). I think there's one potential crash condition in the command processor with this, but can't remember specific details right now. It's easily worked around anyway.
True, memory fragmentation might become an issue, but the Big Dirty Secret of zone memory is that it is already prone to fragmentation as is (and actually contains code to deal with it).
One has to remember that Quake's memory system was developed under the constraints of running on a machine with 8 MB RAM and no virtual address space. A lot of the decisions made with it may have been valid for those constraints, but they're not so valid - and indeed limiting - today.
#443 posted by necros [99.227.131.204] on 2010/10/23 19:32:53
what exactly does the engine use zone memory for anyway? it already has the -heapsize memory.
 Necros
#444 posted by spy [92.46.28.242] on 2010/10/23 19:52:24
as far as i know, the 'zone' command somewhat related with a large/messy .cfg files
#445 posted by spy [92.46.28.242] on 2010/10/23 19:57:42
-zone
Type: Parameter
Syntax: game.exe -zone (bytes)
Description: Specify the amount of memory in bytes to allocate to holding dynamic information such as aliases.
Note: You will need to specify a value such as 512 if you experience game crashes because of too many aliases being loaded into memory. It is not necessary specify any larger value, since this value will work suffice.
Example: game.exe -zone 512
#446 posted by mh [109.79.7.123] on 2010/10/24 16:24:22
Key bindings, the command buffer (used for every time you press a key in-game, includes cfg files which go through the same system), cvar strings, aliases, and certain types of file loading. -heapsize (known as "the hunk" in the engine) is used for loading models, maps and other big things. A part of this "hunk memory" is also used for keeping permanent copies of a part of MDL files so that they don't need to be reloaded between maps.
This isn't the only memory that Quake uses. GLQuake in particular uses several fairly large fixed-size buffers for lightmaps and texture loading (about 8 MB total; Fitz uses more for lightmaps but less for textures), and all versions of Quake use other memory buffers outside of this system for console prints, network traffic (also applies to SP games which go through the same code; will use more if large map support is enabled, and also allocates for up to 4 players as standard, even if you never run an MP game) and other bits and bobs.
OpenGL itself will keep backup copies of all textures in system memory which are used to recreate the hardware copies if you Alt-Tab away, and which were also used for texture swapping in the Bad Old Days of low video RAM. The framebuffer itself may even be backed up by system memory; I haven't found anything to indicate either way.
Windows Task Manager shows a standard unmodified GLQuake with no command-line params as using about 66 MB of memory on my machine, and I doubt if it's much different on yours.
So in other words the amount of memory specified by -zone (or even by -heapsize) is really mickey mouse stuff compared to the overall memory usage of Quake. Being conservative about them seems to be a waste of time and effort these days, in particular when more or less everybody is guaranteed to have 256 MB as an absolute bare minimum, and 95% of people will have 1 GB or more.
#447 posted by necros [99.227.131.204] on 2010/10/24 20:45:16
wow, there's even more going on than i realized...
thanks for the clarification, i'll just go ahead and start suggesting a 2mb zone or something from now on. :)
 Possible Bug?
#448 posted by taniwha [119.171.184.241] on 2010/11/22 12:42:04
I'm in the process of porting protocol 666 into QuakeForge, and I ran into this (in SV_WriteEntitiesToClient):
//johnfitz -- don't send model>255 entities if protocol is 15
if (sv_protocol == PROTOCOL_NETQUAKE && (int)ent->v.modelindex & 0xFF00)
continue;
Shouldn't that be sv.protocol?
#449 posted by gb [89.27.209.50] on 2010/11/22 14:50:08
sv_protocol is the cvar, IIRC.
#450 posted by mh [137.191.242.106] on 2010/11/22 17:25:57
> Shouldn't that be sv.protocol?
I suspect that you're right. sv_protocol is the command whereas sv.protocol is the currently active protocol which only gets updated when a new server is spawned. Using sv_protocol here would mean that server messages would go all wacko if the protocol was changed while a server was running.
 Yeah...
#451 posted by metlslime [159.153.4.50] on 2010/11/22 20:27:53
that's a mistake. I'm not sure what happens if you compare the cvar directly rather than cvar.value ... it's a struct which means are you comparing the first element of the struct?
 Sv_protocol
#452 posted by O.S. [88.234.235.126] on 2010/11/22 20:58:39
.. is not a cvar, it's a global associated with the sv_protocol console command which sv.protocol is assigned to at server creation. So the comparison in SV_WriteEntitiesToClient() really needs sv.protocol and not sv_protocol.
 Ah...
#453 posted by metlslime [159.153.4.50] on 2010/11/22 21:11:12
Yeah it's been a little while since i looked at the code. I guess it works as written but is unsafe. Should be sv.protocol.
#454 posted by stevenaaus [114.73.92.148] on 2010/11/22 21:11:35
Ha ha ;>
Nice to see QuakeForge is getting updated.
#455 posted by taniwha [119.171.184.241] on 2010/11/23 06:49:31
Due to a series of unfortunate events, QF more or less went into hibernation for a few years, though I kept poking at it occasionally (there is no year with 0 commits). I've been fairly busing hacking on things this past year, and lately, the maps on quaddicted have given me some real motivation :). git helps a lot, too (easy branching and stash).
I'm glad to have been of help.
 Bug
When running Fitz 0.85 with -quoth, it's impossible to switch to the id1 gamedir with game id1, because the engine thinks that the Quoth dir is the id1 dir, and thus nothing changes.
 Not A Bug
#457 posted by negke [88.70.243.45] on 2011/01/23 11:21:24
If it weren't like this, certain releases wouldn't work they way they do. Those that come with an extra pak/mod dir but still require quoth as a base.
 But I Know That
I'm just saying that typing 'game id1' in the console should probably revert that behavior.
 Yeah...
#459 posted by metlslime [67.188.81.46] on 2011/01/23 21:40:07
that was implemented by request because BJP quake has it. ideally there would be ways to turn that stuff on/off in the console. (maybe multiple gamedirs like darkplaces would do it.) But to get the alternate hipnotic/rogue statusbars, you'd also need special variables for those.
#460 posted by necros [99.227.131.204] on 2011/01/24 00:30:03
i was really happy you added the -quoth thing, but i guess it does make more sense for a more generalized multimod loading order thing.
maybe there'd be a way to detect what kind of hud layout to use based on what the gfx.wad contains? or are they all the same?
#461 posted by mh [137.191.242.106] on 2011/01/24 10:56:31
if (hipnotic || quoth)
????
 Ideally
#462 posted by necros [99.227.131.204] on 2011/01/24 19:41:16
it would be awesome if it wasn't determined by folder name of the mod so you can make other mods that use the hud without having to get people to do a -hipnotic -game mymod.
checking quickly, the gfx.wad in hipnotic has all those extra weapon icons and id1 doesn't, so they do use different gfx.wad files. is that possible then, to look at what entries are in the wad file and then use an appropriate hud?
#463 posted by Berntsen [158.38.87.186] on 2011/01/26 16:09:47
Hey, I have a widescreen monitor (1920x1080) and changed my resolution in FitzQuake accordingly, and it works fine, except the UI (HUD, console, main menu) is terribly tiny. Are there any commands to prevent them from being downsized while maintaining the proper resolution?
 Sort Of
#464 posted by rj [82.13.31.251] on 2011/01/26 18:38:31
scr_conscale
scr_menuscale
scr_sbarscale
pretty self-explanatory... '1' is the default value, '2' doubles the size and so on. i find 1.5 a nice value
 Cheers
#465 posted by Berntsen [158.38.87.186] on 2011/01/26 20:10:15
Just what I was looking for, also nice to be able to adjust the speed of the console.
 Ahh
#466 posted by rj [82.13.31.251] on 2011/01/26 20:58:17
what's that command? :)
 Scr_conspeed
#467 posted by Berntsen [158.38.87.186] on 2011/01/26 21:31:56
Also, when I started up FitzQuake just now everything suddenly moved twice as fast, as if host_framerate had been altered, even though it hadn't. What gives?
 Ah
#468 posted by necros [99.227.131.204] on 2011/01/26 21:45:16
you must have a 64bit system and dual core (or more) cpu.
atm, there isn't a solution that i know of apart from using a different engine. you can use quakespasm for now, which is basically fitzquake, except it uses some sdl stuff for timing which gets rid of the problem.
apparently, the way glquake (and by extension fitzquake) calculates time is with some method that doesn't take into account more than one processor.
#469 posted by Berntsen [158.38.87.186] on 2011/01/26 21:56:30
Yeah, I do. I normally use DarkPlaces anyway, just thought I'd give FitzQuake a shot. There was nothing wrong with it earlier today though, and I didn't disable any cores or anything in the meantime. Strange...
#470 posted by necros [99.227.131.204] on 2011/01/26 21:57:53
i think i recall some people saying disabling additional cores worked for them, but that didn't work for me.
#471 posted by mh [78.152.247.178] on 2011/01/26 23:54:35
> Also, when I started up FitzQuake just now everything suddenly moved twice as fast, as if host_framerate had been altered, even though it hadn't. What gives?
Quake's default timer is shit and Fitz still uses it. :( 64-bit, multi-core or power saving will wreck it, and it really needs an engine-side fix.
#472 posted by necros [99.227.131.204] on 2011/01/27 00:01:57
iirc, during the discussion, it was mentioned there's an alternative to the way stock glquake does timing without having to switch to sdl.
 Sure
#473 posted by ijed [190.22.61.247] on 2011/01/27 01:21:21
But pasting a .dll in the Quake folder is easy...
 Yeah
#474 posted by SleepwalkR [85.179.158.194] on 2011/01/27 07:54:13
And QuakeSpasm is simply FitzQuake + a bunch of nice fixes. If you like Fitz, you'll like QS as well. It doesn't alter the look and feel of FQ.
#475 posted by gb [89.27.240.198] on 2011/01/27 08:34:01
SDL is a good idea anyway, for cross platform support and for audio stuff etc (able to use a lot of different output devices / sound systems etc).
 Slightly Improved FitzQuake 0.85.exe
#476 posted by Baker [99.54.145.0] on 2011/01/27 22:29:41
1) Clock fix
2) Session to session command line history via the up arrow
3) Half-Life .bsp support
4) Rotating brush model support and extra chase camera options
Source included, of course, and has 2 project files: MS VC++ Express and Code::Blocks
http://quake-1.com/files/engine-so...
Mostly made to satisfy someone who wanted Half Life map support in FitzQuake.
 5 Button Mouse Support
#477 posted by Baker [99.54.145.0] on 2011/01/27 22:48:42
5) 5 button mouse support
^^ Add. Forgot to mention.
#478 posted by necros [99.227.131.204] on 2011/01/28 00:48:05
Session to session command line history via the up arrow
i noticed this in quakespasm and i thought i was going insane for a while before i realized what was going on.
5 button mouse support
you are a quake hero for a week and three days.
#479 posted by Yhe1 [108.23.26.193] on 2011/02/01 21:13:41
Is the next Fitzquake going to have Nehahra support?
 It's Possible...
#480 posted by metlslime [159.153.4.50] on 2011/02/01 21:50:07
I've considered it before, but it was never a high priority. I still need to generate a list of necessary features (e.g. spr32, special protocol for the demos, fake cvars so the fog works, alpha (already done), not sure what else...)
#481 posted by mh [109.79.242.34] on 2011/02/02 16:24:28
Nehahra support is quite tricksy and it doesn't sit too well with more modern engine features. Aside from anything else it does evil things like changing the protocol without defining a new PROTOCOL_VERSION; obviously a relic of earlier times.
 There's A Bug With Weapon Anim Interpolation
#482 posted by necros [99.227.131.204] on 2011/02/10 03:44:51
i can't quite figure out exactly what causes this, but as i am building a map, once the map reaches a certain point in size, weapons stop interpolating their animations.
yeah. wtf indeed. :P
is there maybe like a certain number of slots that fill up for models to interpolate? i haven't seen monsters being affected by this though.
this happens in quakespasm and rmqengine as well as fitzquake085.
 Hmmm...
#483 posted by metlslime [67.188.81.46] on 2011/02/10 09:09:44
weird. I can't even think about how that's possible :|
 But Uh...
#484 posted by metlslime [67.188.81.46] on 2011/02/10 09:10:29
can you send me a map that causes this bug? Or is there an already-released map out there that does? (if it's due to size, maybe warpspasm or something?)
#485 posted by mh [137.191.242.106] on 2011/02/10 13:31:07
That's wacky. Must be a protocol thing then as RMQ's MDL renderer is significantly different.
#486 posted by rj [86.0.166.158] on 2011/02/10 20:13:26
i did actually notice that on an unvised e2m4rq (which is massive) in rmqengine a few months back. seemed to disappear once everything was vised though
 Model Progs/centurion.mdl Not Found
#487 posted by stevenaaus [114.72.223.55] on 2011/02/12 06:01:56
Rubicon 2 looks flashy ;>
But regards the demo crash, is there a reason "Model not found" doesn't throw a Host_Error ?
cl_parse.c:
- Con_Printf("Model %s not found\n", model_precache[i]);
+ Host_Error("Model %s not found\n", model_precache[i]);
 Probably A Silly Question
#488 posted by nitin [124.148.141.142] on 2011/02/19 04:34:52
can fitz play nehahra?
 Unfortunately Not...
#489 posted by metlslime [159.153.4.50] on 2011/02/19 04:38:51
it's on the wishlist though.
 Ok Cool
#490 posted by nitin [220.235.41.84] on 2011/02/19 04:53:53
I couldnt find it in the readme. Would be a good feature IMHO. Aguire/Nehquake engine doesnt appear to be widescreen friendly.
#491 posted by Yhe1 [108.23.26.193] on 2011/02/19 05:17:14
and Directq doesn't support the neh Fog, so we are waiting for a "perfect engine" lol
 Load Last Save Upon Death
#492 posted by quakis [81.111.135.140] on 2011/02/26 17:51:50
It this possible by some toggle or console command I'm missing somewhere? Would be very handy.
 No
#493 posted by necros [99.227.131.204] on 2011/02/26 20:38:28
there's no way to keep track of the last save spot (aside from quicksave) in the qc, and it's the qc that handles what happens when you die. (for button presses and reloading the map).
if the engine had some extended builtin function 'getLastSave' then it'd be a simple matter to hook it into the qc.
#494 posted by quakis [81.111.135.140] on 2011/02/26 20:49:59
That's a shame :( Thanks for the response.
 Are You Asking As A Player Only?
#495 posted by necros [99.227.131.204] on 2011/02/26 20:51:50
or for a mod?
if you implement an autosave system, you can hook that in easily enough so that pressing fire when dead loads the last autosave.
also, if you coopt the quicksave key and redirect it to an impulse, you can assign a function to quicksave as normal, but then you can mark a variable somewhere to remember that the player has quicksaved and to load that save when dead.
#496 posted by quakis [81.111.135.140] on 2011/02/27 21:16:53
Late reply - As a player only. It's simply for convenience since Duke/Doom/HL do it, I've wondered if it were possible in Q1.
 I Implemented That
#497 posted by ericw [161.184.107.29] on 2011/02/28 19:26:53
as an engine patch on Quakespasm (but it could be applied to any engine.) It's really nice; keeps the gameplay pace high when you die - just shoot and you're back in the game :D.
The patch also autosaves every so often, based on a heuristic (picking up health = probably a good time to autosave)
Here is a windows binary:
https://github.com/downloads/ericw...
and the source:
https://github.com/ericwa/Quakespa...
#498 posted by mh [78.152.229.4] on 2011/02/28 22:23:51
I just did it in DirectQ as a restart2 command; it tracks the name of the last save you make and just reloads it if something valid was in there. Probably not very robust (what if the load fails?) but hey! - it's a hack anyway.
#499 posted by necros [99.227.131.204] on 2011/02/28 22:35:06
if you're gonna add it, you should really make it controllable via qc instead. :(
should be a 'getLastSave' command that outputs a text string or something.
restart2 works i guess, though. you just call that in qc instead of restart.
#500 posted by metlslime [159.153.4.50] on 2011/02/28 22:40:24
Probably not very robust
Make sure the save is from same map that the player died on maybe :)
#501 posted by mh [78.152.250.249] on 2011/03/01 03:03:01
Make sure the save is from same map that the player died on maybe :)
(...rushes to source code...)
 And...
#502 posted by metlslime [159.153.4.50] on 2011/03/01 03:16:12
probably you should invalidate the "last save" if you load a map using the map command, or the changelevel command. So you only get a valid save again if you have saved/loaded a savegame since your last map/changelevel commands.
save/load -- sets the relevant savegame as the last valid save
map/changelevel -- clears the last valid save, now restart will go to the beginning of the current level as usual.
 Metl
#503 posted by spy [92.46.9.104] on 2011/03/21 18:59:38
could you look at these demos
http://www.quaketastic.com/upload/...
since i've got a new pc, some strange issues chases me while i'm using fitz085
the 1st one is very strange the plat/lift behavior
and 2nd, weird navigation on an uneven surface(s)
#504 posted by mh [109.79.157.8] on 2011/03/21 19:54:38
Bet you anything you've got host_maxfps set to something higher than 72. If so, set it back to 72 and they'll go away.
 Ok
#505 posted by spy [92.46.23.162] on 2011/03/21 20:39:09
thank you
 For Future Consideration ... External .Ent Support
#506 posted by Baker [99.66.37.26] on 2011/06/01 21:51:33
The ability to load quake\id1\start.ent or whatever with just the entities in a text file instead of loading from the map.
5 second cut and cut paste easy tutorial:
http://forums.inside3d.com/viewtop...
 Icons Change
#507 posted by st3ady [72.81.134.199] on 2011/06/04 04:53:36
I've noticed that whenever I run fitzquake, the icons of quicklaunch/taskbar shortcuts change to random others, such as my notepad icon changes to the MS admin icon, and my firefox icon changed to the camera and printer devices icon, and my open folders icon changed to the media player classic icon. I am running windows 7 64 bit. I also noticed this on my old computer from a few years ago, but I never reported it. That computer was running Vista 64bit. Thanks!
 Resetting My Configs
#508 posted by Berntsen [158.38.86.242] on 2011/06/06 21:57:16
FitzQuake doesn't save any cvars I enter in the console, so I have to reenter all the variables every time I start it up, like scaling menu/hud/console, which is incredibly annoying. I noticed someone else already posted about the same problem, with the solution of entering the variables into autoexec.cfg, but that doesn't appear to work for me. I have autoexec.cfg as well as the FitzQuake executable in my main Quake folder, which I presume is correct?
Appreciate any help.
#509 posted by necros [99.227.131.204] on 2011/06/06 22:03:17
it must be in the id1 folder for it to work. :)
 Cheers
#510 posted by [158.38.86.242] on 2011/06/06 22:11:01
Sweet, that did the trick :)
 Another Mapper-oriented Idea For Future Consideration
#511 posted by Baker [99.54.147.60] on 2011/06/07 20:12:47
Allow mapper to freeze game world like DarkPlaces existing feature. Quicky engine tutorial:
http://forums.inside3d.com/viewtop...
 OUTRAGEOUS GLITCH
#512 posted by negke [89.204.153.231] on 2011/06/11 12:05:19
Or something. It seems Fitzquake treats the self.message thing in secret_touch incorrectly. So what happens is stepping on a secret door (without a message field of course) creates an empty centerprint. This is annoying because it beeps for no reason. Can some verify?
 Well Ok
#513 posted by negke [89.204.153.231] on 2011/06/11 12:20:50
Apparently it's not Fitz's fault but something that happens in conjunction with my id1-devmod. Sorry. And I only just noticed the "use mouse" thing in the options. Is it +mlook or mouse capturing in windowed mode?
#514 posted by negOK [89.204.153.231] on 2011/06/11 14:55:00
Using OPEN_ONCE instead of wait -1 seems to solve it.
 Re: Glitch
#515 posted by PM [72.216.40.118] on 2011/06/11 16:03:06
negke, the glitch may not be a FitzQuake only problem. The problem could be the qc assuming string_null is null all of the time. Unfortunately, this may not be true.
string_null, and all other global strings, are no longer null after loading a savegame. If the qc checks for string_null assuming it is null, it may not work after loading a savegame.
 Request: Raise Default Max_edicts
#516 posted by PM [72.216.40.118] on 2011/06/11 16:12:34
One of the maps in Tronyn's upcoming Unforgiven can exceed the default of 1024 max_edicts. Can there be a minor update to Fitz that increases the default to 2048 or even 4096 max_edicts?
I know of the max_edict command, but I bet Tronyn and I will read many complaints about one map not working because someone failed to read the readme.
 PM
#517 posted by negke [89.204.153.231] on 2011/06/11 16:29:00
If you're refering to the max_edict issue in unf2, it seemed more like an accidental thing, a glitch in the code or some misfiring script. The map itself feels like the least extreme of the pack. Even unf3 'only' starts at ~800. Or what is the exact reason for the edict explosion?
#518 posted by negke [89.204.153.231] on 2011/06/11 16:30:35
Hm, I guess you could write "max_edicts 2048" in the quake.rc to be safe?
 Edicts Explosion Due To Snow Effect.
#519 posted by [72.216.40.118] on 2011/06/11 17:33:49
unf2 has light snow, and it makes the map look pretty, but requires a high number of edicts. With the snow, max_edicts peak a hundred or two below 2000. Related to this is the rain in arcanum1. This is why rain falls in clumps in arcanum1. If I had an edict for each rain drop, edict count would be very high and would not run in FitzQuake without increasing max_edicts. For unf2, I cannot make the snow fall in clumps and still make it look good. Turning on corpse removal will disable the snow.
Other engines with higher default max_edicts do not have this problem.
 Oh Right
#520 posted by negke [89.204.137.161] on 2011/06/11 17:56:25
I didn't think about that. I assume it wouldn't be possible to make the snowfall trigger-based or something and still work/look the same? So that snow flakes are only generated within the current trigger volume. And each outside area is surrounded by a large trigger.
#521 posted by necros [99.227.131.204] on 2011/06/11 19:44:54
One of the maps in Tronyn's upcoming Unforgiven can exceed the default of 1024 max_edicts. Can there be a minor update to Fitz that increases the default to 2048 or even 4096 max_edicts?
I know of the max_edict command, but I bet Tronyn and I will read many complaints about one map not working because someone failed to read the readme.
i kind of wish fitzquake defaulted to protocol 666 (it's own protocol) instead of defaulting to old quake protocol.
i remember back when i released ne_tower, some people didn't change to protocol 666 and some items were invisible to them or something.
the thing is that you can't just force protocol 666 in a cfg file because other engines have their own protocols and this causes crashes.
we need a better way to generally tell one engine 'i need extra stuff' that won't cause problems in other engines.
 Default Protocol
#522 posted by mh [109.79.191.95] on 2011/06/11 21:11:19
Fitz does default to 666 on map load. For demos it will use whichever of the two protocols the demo was recorded with.
One potential problem with a higher default max_edicts is memory usage. The size of an edict is variable, and the way they are accessed by the engine (in particular the VM) makes true dynamic allocation incur a cost in code complexity. Set the default too high and memory costs will soar, even for maps that don't need to use so many.
#523 posted by erc [195.174.19.188] on 2011/06/26 13:57:43
John, do you plan on adding .mp3 support to FitzQuake? In its current state, the engine fits to my needs perfectly apart from this single issue. It's getting tiresome to insert the cd everytime I want to load up a map.
 Unofficial
 Key Door Sound
#525 posted by negke [89.204.137.164] on 2011/06/26 14:29:11
Could it be that Fitzquake doesn't play the proper sound when opening a key door? I think so.
 Onetruepurple
#526 posted by erc [195.174.19.188] on 2011/06/26 14:54:14
Thanks! It works without a hitch. Working link for the .zip:
http://quakeone.com/proquake/inter...
 Negke:
#527 posted by metlslime [67.188.81.46] on 2011/06/27 09:09:02
that is a quakec bug.
#528 posted by negke [89.204.153.204] on 2011/06/27 09:57:43
But it works in some clients. Old winquake for instance. That's how I noticed the difference.
#529 posted by necros [99.227.131.204] on 2011/06/27 20:42:40
you mean that unlocking sound? afaik, it never worked correctly.
in the qc, the unlock sound is played on the same channel that the door move sounds are played on and it is played before the move sounds and it's all done on the same frame, so the engine never even 'sees' the request to play the unlock sound.
are you sure it works in winquake? i can't think of why it would.
 Yeah, You're Right
#530 posted by negke [89.204.153.141] on 2011/06/27 22:56:30
My bad. I must have toggled the console at the right moment or something.
#531 posted by necros [99.227.131.204] on 2011/08/07 19:34:27
i've been experimenting with a rain effect and i'm pretty happy with what i've ended up with.
essentially, it's an edict intensive method: spawn one entity with a sprite model and treat it like a particle for every rain drop.
looks pretty sweet, and with increased max_edicts, it's not a problem since even large areas will only take up maybe 800~ edicts (since max is 32k i'm not worried at all.
problem is that it seems like the engine can't cope with drawing all those models because lightning bolts flicker or just don't get drawn at all.
it's weird because other temp entities like rocket explosions are drawn just fine. it's only the beam effects.
this happens in both fitzquake085 and quakespasm.
using sv_protocol 666 and max_edicts 8192.
#532 posted by metlslime [67.188.81.46] on 2011/08/07 21:40:05
so you're saying -- you have X number of lightning bolts being drawn correctly, then you add your many raindrops, and the raindrops are fine but it causes the lightning bolts to not be drawn?
 Sounds Like...
#533 posted by mh [109.79.191.16] on 2011/08/07 21:44:28
MAX_VISEDICTS is defined to 1024 in Fitz.
 Hmmm...
#534 posted by metlslime [67.188.81.46] on 2011/08/07 21:47:33
well, so this might be the problem:
The lightning bolts are made up of individual segments. Each segment requires a new "temp entity" to be spawned which also occupies a "visedict" slot. So if you reach MAX_VISEDICTS, or MAX_TEMP_ENTITIES, you the rest of the beam segments and any other beams after it will not be visible.
The raindrops wouldn't affect your temp entity budget, but they do use up visedicts if they are visible. So the addition of all these raindrops has probably used up the visedicts (max 1024 in fitzquake) before the beams can get fully drawn. (I believe the beams are added to the list after everything else, so they are the first to go.)
#535 posted by necros [99.227.131.204] on 2011/08/07 21:54:08
so you're saying -- you have X number of lightning bolts being drawn correctly, then you add your many raindrops, and the raindrops are fine but it causes the lightning bolts to not be drawn?
yes, this is it exactly. :)
 So Yeah...
#536 posted by metlslime [67.188.81.46] on 2011/08/07 22:55:53
aside from using another engine or modding fitzquake, i would recommend trying to optimize raindrop count by only spawning rain when the spawner entity is within a sphere around the player (e.g. 512 or 1024 units), since far-away drops will be less visible anyway. Unfortunately, that's probably the best approach :(
Or switch the behavior so up close the drops are independent, but past the middle distance you spawn fewer instances of a second model which is a clump of drops?
#537 posted by necros [99.227.131.204] on 2011/08/08 00:32:52
some experimentation is in order i guess.
thanks anyway. :)
 Max Edicts, Etc.
#538 posted by Baker [69.19.14.34] on 2011/09/24 11:21:29
FitzQuake 0.85 protocol 666 supports 32000 entities/edicts, 32000 being a rather huge number. Server edicts eat up a ton of memory, client entities not so much.
Throwing one idea out there ... well, less of an idea since I've already done it, is to count the entities in the entity string [while ...strstr(entities, "classname")] and then on the client side use the server's estimate if sv.active. Requires moving allocation of sv.edicts to after loading the map and another block of code. Beats allocating 8192 edicts or 32000 and also beats running out of edicts. You might call this the "max_edicts 0" option (if not specified, "guess").
----------
r_nolerplist or whatever it is called. This code doesn't properly check for null termination and can drift off into memory beyond the cvar string. Just by chance it actually doesn't do this with the default string. Not really important, but throwing it in the thread.
I hope someone comes up with a "standardized" rain/snow effect that can be used that ... well .. isn't QuakeC. Snow/rain fall into the fog/particles department and if not, fall into the "view presentation" and not the 3d world. Can you imagine how large a demo would be with 2000 rain particles being written every frame.
I know there isn't a standardized plug-and-play compressed and predictive protocol for coop at the moment, but I kinda of think this is not far off (considering the list of hated engine challenges/problems has shrunk considerably in the last 2 years or so).
Someone needs to solve the rain/snow thing. It looks so nice in Nehahra ... and then turn it into 3 or 4 worldspawn params or optionally as a "rain" or "snow" command in the console.
#539 posted by necros [99.227.131.204] on 2011/09/24 16:07:19
I hope someone comes up with a "standardized" rain/snow effect that can be used that ... well .. isn't QuakeC. Snow/rain fall into the fog/particles department and if not, fall into the "view presentation" and not the 3d world. Can you imagine how large a demo would be with 2000 rain particles being written every frame.
i hope NOT. i tried using Darkplace's rain effect and it's just terrible, mainly because there's just no control over the thing.
if you want to have your own simple drops next to a wide open torrential downpour, your drops end up looking different. the current implementation i have for DP doesn't use the DP effect at all.
Built-ins suck! :P
or if you're going to do it, you must give total control over it so it can be properly integrated into the rest of a mod. ie: the ability to specify what model to use (not just a built in effect), initial speed, how much gravity affects it (if at all), collision and fine control over when and where a drop falls.
#540 posted by Spirit [80.171.155.190] on 2011/09/24 16:39:08
Would FTEQW's particle system help?
#541 posted by gb [46.142.54.96] on 2011/09/24 19:11:15
have you tried actually talking to Lord Havoc about the rain effect?
I can second FTE, it is an awesome engine and Spike is an awesome guy. IIRC FTE recently had its renderer rewritten and should also run more stable now than in old times. Give the nightly builds a try.
otherwise you can always use func_emitter from extras with a rain sprite you make yourself (e3m1rq did this, but the raindrop model sucked).
Maybe DP's effectinfo.txt allows you to alter rain drops?
#542 posted by necros [99.227.131.204] on 2011/09/24 19:24:29
have you tried actually talking to Lord Havoc about the rain effect?
no, and, i don't want to. not really interested in having to chase after someone else for personal changes (and likely bug them too).
as for fte, i was told it wasn't really a modding engine, so i didn't invest too much time into trying to figure it out.
also, it turns off mouse accel in windows and doesn't re-enable it when the engine closes, which... i don't know, why does it even disable it in the first place? just needlessly annoying.
anyway, yeah, my foray into fancy custom engines was not a fun one, so i hope FQ stays close to what it is currently. even after all this time, i still consider it perfect (except for that multicore timing problem, which is easily fixed).
 How Is The Multi Core Problem Fixed?
#543 posted by jt_ [174.252.246.160] on 2011/09/24 20:04:59
I quickly searched through the thread and didn't find threw answer. :x
#544 posted by necros [99.227.131.204] on 2011/09/24 20:10:10
no idea, personally. but from what i recall when the problem first surfaced, it has something to do with the timing function (or whatever) used, and replacing it with a newer function fixes it.
quakespasm has this fix, which is what i use.
i believe baker may have made a version as well? but i have no idea where to get that.
 Texture Transparency?
No texture transparency support of any kind? TGAs alpha chan dosent work, couldnt find anything about it in the radme either. (((
Any hope of getting texture transparency for fitzquake at all?
#546 posted by metlslime [67.188.81.46] on 2011/11/20 22:17:11
Yeah, there's hope. How do other engines do it? Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?
The main work in implementing it is creating a sorting algorithm for transparent objects (and maybe for individual triangles) a nd then rendering them in the right order. I assume most engines either don't bother or they do it per-object only.
 To Confirm This Is Hard
#547 posted by Preach [77.98.165.95] on 2011/11/21 00:24:47
This is not solved in, for example, darkplaces*: polygons with alpha transparency do not render properly against triangles from the same model behind those polys. You end up seeing the background behind the model rather than the rest of the model geometry as expected.
*At least last time I bothered checking...
#548 posted by mh [109.79.157.174] on 2011/11/21 02:50:39
I solved this in DirectQ but it does involve sorting everything on a per-poly basis (rather than per-model, which would be standard for most). It's not hard but it is messy. You should probably also sort particles, water surfaces, sprites, MDLs (which I left sorted per-object rather than per-tri for performance reasons), and possibly other stuff into the same list.
(Aside: There is still a case where 3 or more triangles could partially overlap each other, and which no sorting algorithm could solve. That needs proper order-independent translucency, at which stage you've raised the hardware requirements for the engine so high that few enough people would be able to run it.)
What I did not do was allow for any TGA (or other type) with an alpha channel to have transparency. There are a lot of other BSP format-related problems with this, and ultimately Q1 BSP is just not set up for it. If nothing else, these polys would need to be treated the same as water for visibility determination/portalization, but still be able to generate clipping hulls, which I believe Q1BSP just does not allow at all.
You would need to make them "*" models which is one potential workaround. It would probably also make sense to have a texture naming convention for them, so that you're not slowing down load times by scanning every TGA for alpha (although some engines already do that anyway).
 Metlslime
"Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?"
Yes, apparently thats what they all do.
DP has no problem sorting huge number of bmodels with alpha. But slapping the translucent tex on the entire ground caused some minor sorting issues.
http://imgur.com/a/Zto3F#5
 Spd, Is That You???
#550 posted by negke [78.54.74.0] on 2011/11/21 10:42:32
Very nice screenshots, pretty dark though. Good to see you're working on a town map - I don't have to feel bad for not finishing mine then.
 Sv_main.c World Sub Models Models > 999
#551 posted by Baker [65.60.129.204] on 2011/12/09 11:21:15
sv_main.c world sub models models > 999 can overflow string buffer.
szo fixed this in Quakespasm:
http://forums.inside3d.com/viewtop...
 Whoops...
#552 posted by metlslime [159.153.4.50] on 2011/12/09 20:12:44
good catch, thanks for the info
 Fitzquake Crash
#553 posted by DaZ [2.96.233.159] on 2011/12/11 18:41:57
I noticed that Willem's White Room map hard locks fitzquake085 (have to ctrl+alt+del) but not fitzquake080. Happens for Negke also, I've got no idea why just giving a headsup :)
 Ah :)
#555 posted by DaZ [2.96.233.159] on 2011/12/11 19:02:31
Ok its a known issue, I missed that!
 RE: Fitzquake Crash
#556 posted by szo [78.184.225.151] on 2011/12/11 19:54:09
Fixed in quakespasm since version 0.85.4. See here for the fix, which is actually from quakeforge:
http://quakespasm.svn.sourceforge....
 Shambler's Lightning Animation Not Interpolated
#557 posted by ToMaHaKeR [93.143.226.240] on 2011/12/31 01:38:54
FitzQuake 0.85 on Windows: Shambler's lightning attack animation not smoothed, even with r_lerpmodels and r_lerpmove enabled and r_nolerp_list cleared. Not a big deal, but still.
#558 posted by mh [109.79.241.224] on 2011/12/31 16:27:28
That's intentional; Fitz doesn't interpolate when an entity goes into a muzzleflash frame.
#559 posted by necros [99.227.132.108] on 2011/12/31 18:40:15
i think it might be something else (or the muzzle flash no lerping is linked to .owner in some way?) because checking the 106 progs, the muzzleflash is played on the shambler, not the lightning entity.
 New Feature Idea
#560 posted by DaZ [2.96.230.36] on 2011/12/31 21:17:06
Just a quick brainfart, thought I would post it to see if anyone else found it interesting. No idea if its even possible or easy to implement! :)
A worldspawn key for map specific colour grading / tinting.
Something like _colourmod R G B that will tint the screen image to the mappers preference. So if you have a slime/green themed map you could accentuate the greens/yellows slightly to give a customized final look. Together with fog some interesting visuals could be achieved.
/2 pence
#561 posted by necros [99.227.132.108] on 2011/12/31 21:20:47
uhhhh what? you mean tinting the screen like a v_cshift command but automatically?
 V_cshift
#562 posted by DaZ [2.96.230.36] on 2011/12/31 21:33:38
I've never heard of this command :) I just tried it but im unsure what values it wants to do anything ;)
A suppose a simple explanation of what im on about would be that you could enter a theoretical "_colourmod" with values of .5 .5 .5 which would desaturate the entire image by removing half of every colour.
 It's The Muzzleflash...
#563 posted by metlslime [67.188.81.46] on 2011/12/31 21:47:29
mh is correct: the shambler attack has 7 frames in a row with EF_MUZZLEFLASH enabled. Fitzquake is set up to not lerp frames that have that effect, because usually it's accompanied by muzzle flare geo poking out of the front of a gun, which looks bad when lerped (i.e. on grunt, enforcer, and all player weapons.) Unfortunately it is an unnecessary feature for the shambler lighting attack.
If you don't like that feature, you can set r_lerpmodels to 2 instead of 1 and it should ignore those special exceptions. But, this will also disable the r_nolerp_list feature...
Ideally (note to RMQ team), there would be a way for quakec to tell the engine when lerping is acceptable (EF_NOLERP?), and even which frame to lerp to, and how long to spend lerping. This would only work with progs.dat written to provide that extra information, which is why all quake engines have to make various assumptions to try and make lerping look good. For example, Fitzquake uses .nextthink to guess how long to spend lerping, and EF_MUZZLEFLASH and r_nolerp_list to decide when it's a good idea to lerp.
 Interpolation
#564 posted by mh [109.79.119.4] on 2012/01/02 15:23:46
With DirectQ I decided that if a vertex moves 10 or more units from back to front between frames 0 and 1 then it's not interpolated. It works well with all current content, but of course something is going to break it at some point in time. That's something I accept for now. I didn't bother with enemy muzzleflashes.
For RMQ we're building new content and it can be made interpoaltion-friendly from the get-go.
#565 posted by necros [99.227.132.108] on 2012/01/02 18:40:58
this is done per vertex?
like, if a zombie swings it's arm, the shoulder and upper arm are lerped, but the lower arm and hand (since they are moving fast) are not?
 JoeQuake Lerps Per Vertex
#566 posted by Baker [69.47.165.224] on 2012/01/02 20:24:11
And in some cases it works great.
It some cases, if you rapidly press pause and then unpause ... you see the most foobared looking thing imaginable.
I'm talking view weapons here.
 Necros
#567 posted by mh [109.79.136.85] on 2012/01/03 20:48:47
It's a little more complex than that.
First of all it's only done with the view model. The check is actually run inside of R_DrawViewModel so that's absolutely guaranteed: "if (!mod->delerped) {Mod_DelerpVertexes (mod); mod->delerped = true;}" or something like that. The viewmodel also runs a slightly different code-path, so even if somebody did decide to use zombie.mdl as a viewmodel (those wacky modders!) it's also guaranteed to not happen with regular zombies too.
Secondly, it only checks vertexes that move between frames 0 and 1 of the model (if the model has only 1 frame - and there are some - it doesn't bother). So no matter how much a vertex may move in any other frame doesn't matter and doesn't affect the result; it's only "if it was in this position in frame 0 and in that postion in frame 1" that counts.
Thirdly, it's only movement in the back-to-front direction that is measured. So apply aliashdr_t::scale and aliashdr_t::scale_origin to the positions in each trivertx_t, then check the difference between element[0] of each - over 10 indicates a positive result - this vertex was way at the back of the model in frame 0, in frame 1 it's way out at the front, so we don't want to interpolate it.
The result from this comparison carries through to other frames, and so far it's proven to be valid with all ID1, Rogue, Hipnotic, Zerstorer, Quoth, etc weapon models (it even worked perfectly with Hellsmash) - it successfully removes interpolation from the muzzleflash verts, and only from the muzzleflash verts.
I have an idea that a nicer implementation might be to weigh the blend factor depending on the distance between the current and previous verts for any pair of frames; that could be run on the GPU in a vertex shader, wouldn't need any special case handling, and it's something I may experiment with some day.
#568 posted by necros [99.227.132.108] on 2012/01/03 21:21:57
oh ok, i didn't know if was only for view models.
sounds like you've got all the bases covered i guess; i've never looked at the engine code much, so i don't really get the specifics of it all.
 Huh
#569 posted by ijed [190.22.100.123] on 2012/01/04 01:40:29
So that's why the lightning effect on the RMQ Cauteriser interpolates, even though that's not intended.
So with the proposed solution it'd just be a case of moving the lightning part of the mesh very far back in the 'miss' frames.
#570 posted by mh [109.79.136.85] on 2012/01/04 03:14:42
Yup; just move it as far back as possible in frame 0.
I tried the vertex shader idea, and it works fairly well. Things are occasionally jerky during dying animations, but it's a reasonable enough general solution. I think I might save it up as a fallback if my current method ever breaks.
 Smooth Lite Bolt
#571 posted by ToMaHaKeR [93.143.161.13] on 2012/01/04 14:28:29
Is it anyhow possible to smooth the movement of the lightning gun bolt (when you fire and sweep around with that weapon)?
#572 posted by necros [99.227.132.108] on 2012/01/04 18:27:33
that is a different problem from the view model interpolation issue.
i got around this problem in ne_ruins by changing the lightning code to update the beam position every frame. this gives an extremely smooth smooth sweep. you also need some code to maintain the old 30 damage per 0.1 seconds as well as a way to keep track of missed damage (if the player gets less than 10 fps) but that's not a big deal.
 The Bolt Effect...
#573 posted by mh [109.79.171.27] on 2012/01/04 19:19:43
...is also framerate-dependent. If you're running at 20fps it looks different to if you're running at 1000fps, because the engine assigns each bolt segment a random angle each frame.
#574 posted by necros [99.227.132.108] on 2012/01/04 19:39:16
yeah, that bugged me a lot. i've been building custom beams out of entities lately. more control that way too.
 FritzlQuake - Most Captivating Quake Experience Ever
#575 posted by negke [31.18.178.13] on 2012/02/04 10:40:42
Literally now. Ever since installing the latest Nvidia driver (I believe), FQ doesn't work in fullscreen anymore. The screen is just black and there are no sounds. I can't alt-tab or reach the task manager to close it. Apparently Windows is still active in the background, at least ctrl+alt+del and random key mashing seems to do something - i often hear the Windows logout sound - but it's impossible to bring it back, so only a reset helps. No problem in -window mode, and QS can be run in fullscreen fine.
I had somewhat similar problems with DirectQ every now and then. However, there the monitor would at least show an "out of range" message.
Any idea what I could do to fix it - or get more information on what's going on?
#576 posted by necros [99.227.132.108] on 2012/02/05 00:33:09
have you tried forcing the screen res with -width and -height?
 What Necros Said
#577 posted by Mr Fribbles [118.209.88.171] on 2012/02/05 00:39:33
Mind you, I find that unless I am setting it to the monitor's native resolution, changing the res via the command line will cause a black screen, but the app hasn't locked up - I can alt-tab back to it and it fixes itself.
 P.s.
#578 posted by Mr Fribbles [118.209.88.171] on 2012/02/05 00:42:22
Also try changing the video settings stored in the config files to what you want if the command line force doesn't work. Might be worth a shot.
#579 posted by mh [109.79.174.125] on 2012/02/05 01:41:28
I'd double-check what you're setting for refresh rate and bpp too, as it definitely seems like you're trying to select a mode that hardware acceleration isn't available in but that is nonetheless being reported by the engine (perhaps one of the low res modes?)
 A Request Re: External Textures
#580 posted by necros [99.227.132.108] on 2012/02/07 02:27:21
is it possible to scan the 'wad' key in the worldspawn to get the texture wads used, and then, when loading external textures, also look in folders named the same as the wad files?
map is mymap.bsp
so my worldspawn has:
'wad' 'gfx/common.wad;gfx/quake.wad;gfx/...
so fitzquake would look in:
/textures
/textures/mymap
/textures/common
/textures/quake
/textures/hipnotic
this would make keeping external textures folders organized a simpler task, especially if you have a map pack with more than one map referencing the same texture without having to resort to mixing all the packs together into /textures.
#581 posted by necros [99.227.132.108] on 2012/02/07 02:28:59
crap...
'wad' 'gfx/common.wad; gfx/quake.wad; gfx/hipnotic.wad'
but all together, without spaces (like normal).
#582 posted by mh [109.79.224.170] on 2012/02/07 03:43:25
I personally think it's a more elegant approach than using the map name, but it has the disadvantage that when multiple wads are used it must attempt an extra file search for each extra wad. Depending on how many textures you have, how many of those are already cached, and how many image formats you support, it could measurably slow down map loading.
There's also the fact that using the mapname is standardized in so many texture packs.
I suppose you could do both and cache a qboolean for whether or not the search path exists after the first attempt.
|