|
|
| Posted by metlslime [24.130.223.174] on 2009/02/12 13:04:24 |
New in this version: increased map and protocol limits (can load all known limit-breaking maps,) model interpolation, per-entity alpha support, new network protocol, more external texture support, hardware compatability improvements, many bug fixes, and a cleaner source release to make it easier to install and compile.
Go! http://www.celephais.net/fitzquake
(Thanks to the beta-testers: Baker, JPL, negke, Preach, and Vondur.) |
|
 |
 |
 |
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 :)
 |
 |
 |
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...
 |
 |
 |
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, ...)
 |
 |
 |
#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.
 |
|
|
| #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.
 |
|
|
| #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?
 |
|
|
| #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...
 |
 |
 |
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.
 |
|
 |
 |
|
Website copyright © 2002-2010 John Fitzgibbons. All posts are copyright their respective authors.
|
|