For Some (very Good) Reasons
... I'm not using it anymore :P
Is the business.
Can somebody explain what the -nomtex command line option does?
That disables multitexture rendering.
Can you explain a little bit more in depth? I was wondering how disabling the multitexture rendering helped the dynamic light speed up issue.
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.
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
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?)
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.
There seems to be some issue with ATI.
Some german guy reported this:
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
at work (shhh) ;)
any idea, does he have this issue with all glquake engines or do some have fixed behavior?
Dunno, I could ask him to try some. Which ones would be good? aguirRe's and Joequake maybe?
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.
That fixed it for that guy too. Thanks!
Maybe make 32 bit the default in the future?
Doesn't it run slower then?
These days? I can't imagine.
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.
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.
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
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).
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
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]).
is this just the switch from a float to a double for the system time calls?
#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.