Some weird micro frame skips on some heavy maps
One example is ct3tourney3, on some parts of the map where there are many things to render I get some micro frame skips, is not stutter, no noticeable audio interruption nor unregistered inputs (the mouse movement is fluent and precise but the frame (pacing?) is not) I tried to see on MSI afterburner if there are framerate or frame timing inconsistencies but the graphs show an almost perfect horizontal line, stable 144 no frame drops. I also tried with pure vanilla but no luck I honestly could use some help, I don't have any idea of what's happening Is it an engine limitation or are there some cvars that I'm not aware of?
These kind of issues are hard to fix, especially if you don't provide any more information. Can you at least mention the minimum, usual information, please? What renderer, cfg settings (default or not), sytem specs, with or without bots, etc. It would also help a lot if you would provide either a small screenshot from the place of the map where you encounter the issue, or at least tell us the coordinates (join the specatator and type 'where'). As far as ct3tourney3 is concerned I can't reproduce the issue. What helped me a lot in general (with all idtech3 games) is to always set r_swapinterval to 1, also set r_finish to 1, the combination of those two cvars will make most idtech3 games really run very smooth. Those cvars are not recommended for competitive gameplay (which Q3e is made for, afaik).
Here you go sorry for the lack of info
q3config.zip
It is most noticeable while strafe jumping around
I have the same cvars set to 1 and it's buttery smooth almost on every map, except the more complex ones (5% out of 700 maps)
Probably it's my laptop processor again, it got me previously into trouble with certain rare ctf maps with bots activated
What's weird is that iput wise the game keeps being flawless, but display wise it gets very annoying
Could the problem be the refresh rate? I have a 144 hz display and set 144 in the config, should I change that?
(I've encountered the same micro frame skipping in only one more instance, in UT2004 and UT, also a rare case)
Okay, I checked it again (with your cfg, and a fine tuned ping-o-meter) to detect some micro-inaccuracies. As you can see on the left side of the screenshot, there are no obvious problems, at least on my machine. Even if I move around in small steps/jumps I can't see any inaccuracies.
Maybe some app on your machine causes the micro frame skips, idk. Disconnect from any network, quit any anti-virus software, background apps and whatnot, and try it again. You can also monitor which system processes are running, maybe some processes are stressing your CPU.
Sorry that I can't really help you at least for now.
EDIT: if you encountered the same micro frame skipping on other games as well, it is very likely that there is some bottleneck on your system/hardware, ... and even if they tell us the opposite, laptops aren't really made for excessive gaming imo.
Could you give me the cvars you used to monitor the performance in-game?
The ping-o-meter isn't part of Q3e, I just use it to find nasty flaws. Maybe, you can find it in some of the Urt forks of Q3e, idk.
Where can I find the one you're using?
I don't know, I use my own, based on a very old Urban Terror version when one of the old Urban Terror members firstly switched from ioq3 to Q3e, or at least wanted to. I made a modified patch that I can apply on a unmodified Q3e fork, just for debuging. I don't follow all Q3e forks, so I don't know if, or which, Urban Terror fork still has their ping-o-meter. You can find all Q3e forks here: https://github.com/ec-/Quake3e/network/members (some are Urban Terror forks). The main threads of Urban Terror are here: https://www.urbanterror.info/forums/topic/18972-optimized-exe-builds-of-ioq3-engine/ and here https://www.urbanterror.info/forums/topic/14251-networking-lag-meter-and-gaming-consistency-guide-to-urban-terror/ both are pretty dead, but ping-o-meter is explained there.
I'll take a look it also says it increases performance, crossing fingers
2560 x 1440
seta r_ext_supersample "1"seta r_hdr "1"
On mobile GPU, really?
Nope, I have 1920x1080. I swear it's buttery smooth except on those rare maps. I don't get any drops with supersample compared to multisample 8x
I don't see any anomalies there, even on integrated GPUs, it seems like skybox takes significant amount of drawtime in some world positions, nothing more, try without r_hdr - that may eliminate some constant GPU usage caused by HDR->SDR surface conversion

Ok when I get time I'll use your same tool and look if I get similar results. I'll try with r_hdr enabled and disabled
Excuse me, is that "Graphics Frame Analyzer" tool this stuff from Intel? https://www.intel.com/content/www/us/en/developer/tools/graphics-performance-analyzers/graphics-frame-analyzer.html Does it only work with Intel video adapters?
Yes, IIRC nvidia/AMD has similar tools too, you may use universal tools like RenderDoc but reported metrics will be not very handy
One example is ct3tourney3, on some parts of the map where there are many things to render I get some micro frame skips, is not stutter, no noticeable audio interruption nor unregistered inputs (the mouse movement is fluent and precise but the frame (pacing?) is not) I tried to see on MSI afterburner if there are framerate or frame timing inconsistencies but the graphs show an almost perfect horizontal line, stable 144 no frame drops. I also tried with pure vanilla but no luck I honestly could use some help, I don't have any idea of what's happening Is it an engine limitation or are there some cvars that I'm not aware of?
Are you using a multimonitor setup? I got microshutter when second screen is attached but disabled in Nvidia control pannel. I see bad frametimes in capframex. If second screen is enabled or complete power off (no standby) the microshutter is gone.
It seems there is a problem with Nvidia drivers as they are polling the second screen when it is in standby. Every time the driver is polling the screen microshutter apears.
Something interesting: apparently what makes the map stutter is the audio itself, and why it happens only in specific areas of the map. Still not sure if it's related on how many audio files get played at the same time, or the frequency, or both