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 

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. 

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. 

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. 

(Sometimes) You rock!

I was bugging metl the other day when that merge would happen and expected it some time in 2010. 

It's just a lot of busy work to do it really.

I'll let you do the compile on Linux ;) 

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. 

A Mac engine which supports limit breaking maps!?!??!! A benchmark has been hit!!! :))) 

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. 

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! 

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. 

OS X binary:

http://quakeone.com/proquake/src_other/fitzquake_sdl_085_beta_1.zip

Source:

http://quakeone.com/proquake/src_other/fitzquake_sdl_20090510_src_beta_1.zip 

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/files/fitzquake_sdl_085_beta_1.tar.gz
Careful, it's a tarbomb (well, just two files inside). 

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). 

Broken limits in multiplatform are now a thing of the dark ages then, or soon.

Good work.