Max_mode_list

[r00k]

I'm trying to find the correct value for MAX_MODE_LIST (i think thats the variable) for vid_init. Quake defaults to 30, but I had upped that value in the past to allow more refresh rates for each resolution. A few players now have 4k monitors and I wanted to increase the modes to allow for higher resolutions. But the problem I'm having is finding the correct value; as if I say put it at 600 it takes almost 5 minutes to initialize the game on some machines...

thanks

[frag.machine]

I don't think there is a "correct" value to MAX_MODE_LIST (I suspect it was set at 30 back then for convenience when drawing the list).
Are you sure the query to is the culprit here ? From what I read in the documentation the first call passing 0 as the desired video mode should create a cache to the info in all available modes, so subsequent calls would be fast.

[r00k]

it's something in vid_init
pressing f11 (trace-into) anytime i pressed it would traverse quickly but once it hit vid_init_FULLDB it took awhile.
I dont have shaders enabled but that's how long it feels like; as if its compiling shaders before the black screen then menu shows up.

edit: wonder if it's just a wondows 10 thing 'cause my xp laptop loads it up in 5 seconds, yet my windows10 machine with a 960 gtx and an intel i5 + ssd takes over 10seconds.

[Spike]

the way I see it, modes are obsolete. windows won't report 320*240. drivers can scale pretty much any sized image to full screen (or letterbox them), or your monitor can. etc.
when you combine all of that with refresh rates and colour depth and stuff, things get even worse.
imho its better to have an internal list of common width+height values and filter based upon the desktop's size.
this is why fte has only width+height+bpp+refreshrate cvars, and no modes at all (the menu has a list of common resolutions but they're basically just hints and exist solely in the menu). and if width+height are 0, then it uses your desktop's resolution because frankly that's usually the only resolution that will actually look correct (unless you care about pixel doubling, but even then you often get some ugly bilinear filter or double letterboxing or both).

if nothing else you should split size and bpp+refresh rate. there's too many possible modes otherwise.

[Baker]

Does Quakespasm have this problem on your Windows 10 machine?

If no, then it isn't EnumDisplaySettings being slow. Although Quakespasm is SDL, the SDL functions for getting available video modes just callls EnumDisplaySettings.

You may also try a different NVIDIA driver version, it is remarkable how often they put out a update that causes serious issues in some rare circumstances but it seems like it is 2 times a year.