A RMQ feature, but it got bugger and went to /bed. 

hi again, found an issue with the sdl2 builds, both stable and dev. every time i start the engine in fullscreen mode with resolution lower than native, the screen flickers terribly as if half of the frames are dropped. it goes back to normal if i vid_restart or alt-tab. native resolution works fine, as well as windowed and borderless fullscreen modes. that doesn't affect sdl builds. graphics card is nvidia. 

Reproduced that right away on 0.90.1 launching with "-width 1920 -height 1080 -fullscreen" on Windows 10. Will investigate it..
It seems fine if you switch within the video menu. 

I think I fixed it, there is a dev build here 

i had switched from the video menu. 

Dynamic position info, aka r_speeds + viewpos , in svn. Maybe this is useful ? Feel free to modify. 

>cannot see menu after alt-tab out to desktop from the menu (no map loaded)

>R_novis 1: models, doors and sprites are not visible looking into the water, and while submerged looking out

>sometimes can get stuck going down/up ramps/angled brushes, touching obtuse (convex) corners

>committing suicide with a thunderbolt in fluid without gibbing prevents respawning

Requests
--
*Read files directly from the folder, so user can drag & drop models/sounds etc

*r_telealpha, r_lavaalpha, r_slimealpha; those commands dont exist and r_wateralpha affects all fluids 

issues:
for 1) not sure what's happening, could you post a screenshot?
2) that needs a new sv_novis feature. agree that would be useful to have.
3) not sure if we can do much. you can try lowering host_maxfps to 60 from 72.
4) not sure.

requests:
1) I think you're noticing that assets in a pak file have higher precedence than loose files. we can't change it at this point, best bet is to put new assets in a mod folder like quake/mymod/progs/xxx.mdl, then they will override id1 assets when you launch with -game mymod
2) lavaalpha etc. are in the nightly builds 

Quote "sometimes can get stuck going down/up ramps/angled brushes, touching obtuse (convex) corners"

Actually, this could be a problem in the map. Small invisible walls that stop normal movement over what looks like a smooth surface can be caused by CutNodePortals_r warnings during the bsp process not being fixed. 

I thought that was a common hull expansion bug caused by silly old trigonometry 

never mind the comment about host_maxfps, I was thinking about the bug where elevators sometimes hurt you. 

Could just be a coincidence, because I've gotten invisible walls without having any errors or warnings during compile and I've had CutNodePortals warnings that didn't cause invisible walls.

But many times I have run into invisible walls exactly where the compiler said there was a CutNodePortals problem.

Either way, I don't think it's a problem specific to Quakespasm. 

CutNodePortals sounds more like something to do with visibility. Any engine folks have any info? 

It's a QBSP warning, I don't recall ever seeing it during VIS. It's generated during the hull building phase I think.

I got tons of them while working on my Jam 6 map, but I fixed all but one. It was outside the playable area, which didn't make much sense to me, so I figured it wasn't worth worrying about. 

Rick - Yes, I've gotten invisible walls and clipping problems in cleanly compiled maps as well. Quake is old and crotchety... 

Some collision issues are the result of bugs in the qbsp code that expands brushes for the clipping hulls. I believe Aguirre or tyrann fixed some if those bugs in their versions of the tools a few years ago. Not sure if there are still such bugs in the current tools. 

I still get clipping issues like the one described above and I am sure I am running the latest stable release that ericw put out 

Just wondering if this has been considered as an addition to this engine? I'm more looking for the ability to have higher vertex precision than anything else because MDL can be rather brutal if you try to add any subtle details on large meshes. Pointy teeth on a shambler would be an example... I've seen a few other now dead Q1 engine updates that added MD3 support to their builds but those are dead and unsupported developments unlike the lovely Quake Spasm. 

in the custom engine thread.

I for one would be over the moon if QS supported md3. Once you start adding long swords and stuff to monsters and big swinging attacks, the .mdl format becomes a real problem. 

backward compatibility is a real issue. the whole point of .md3 is to do stuff that would look terrible in .mdl, so there's not really a decent option to fall back on.

I'm inclined to start thinking about composite models as a way to workaround the mdl vertex butchery, but I imagine that's another big can of worms. 

 

 

I am all for textures with no filtering and even playing at 10fps for the models with or without interpolation... but integer precision is inexcusable in this day and age regardless. Its just unsightly jitters. We support colored lights for that reason. Sure some folks will make a disco map but these features allow for folks that know what their doing the little bit of extra flexibility.

Besides if folks want to keep the oldschool look for their monsters or create them to work with MDL then feel free. I would prefer to not see vertex swimming on my subtle idle animation that has spikes on the back or toothy maw. 

The biggest issue I have is with the vertex precision dropping indeed with bigger models or making animations that take up a bigger volume for limited frames in your models animation frames. Because MDL takes those ranges as the maximum and then scales up the volume of detail that everything else gets. So either you stick to small critters or big creatures with limited range of motion to avoid losing detail.