 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
thanks. No luck so far, I tried loading that config and doing a "timedemo demo2" followed by "q", tab.
Could be it needs the combination of config.cfg + autoexec.cfg to reproduce ok when i get home i can upload the configs
i can even make a video im using the win64 build also if that makes a difference. i know its not a big issue but if your like me i hate when something breaks without knowing why ;) Shame about having to use the Launch Engine feature, since it's many more clicks than just Run Tool... I might just deal with the mouse snapping unless this is never going to be fixed, since I usually just jump into the game to check lighting and entity placement anyway...
Perhaps in the future a Launch Engine operation can be added for the Run Tool recipes... @pritchard roll back to a version that works?
@ericw quakeone.com/qrack/dev/ config.cfg and autoexec.cfg yet i tried on my laptop winXP no crash so please dont lose sleep over this. :) if you know how to roll back a Windows 10 update, please let me know :P
I decided to open an issue on the TB2 github, but I'm doing it as a feature request for making an engine launch part of the compilation process options as I get the feeling that running it as a "tool" is not ever going to be properly supported. Necros' compiling GUI requires no clicks.
Leave GUI running in BG Save map. Alt+Tab to GUI Ctrl+C to compile. https://imgur.com/YgIacZt If you dive in, it's quite powerful: https://shoresofnis.wordpress.com/utilities/ne_q1spcompilinggui/ Do r_scale 4, then gl_texturemode 6. Enjoy your bleeding eyes!
What do I do, so the pixels don't dance around on the further away objects, when using texturemode 1 and r_scale 2,3 or 4? What do I do, so the pixels don't dance around on the further away objects, when using texturemode 1 and r_scale 2,3 or 4?
gl_texturemode 1 is the equivalent of GL_NEAREST, which disables mipmapping and which therefore causes the pixel dance. You can't do anything because you asked for mipmapping to be disabled, and you got what you asked for. You can try setting it to 2 or 3 instead. My problem is that mipmapping makes everything washed out. This is probably the obvious reason for usinge MORE pixels instead of less🙃 Duh, then Winquake look might not be my favorite...
Win/Software Quake used mipmaps on world/brush surfaces; it didn't on water or MDLs. Typically Fitz/QS replicates this behaviour.
Mipmapping was specifically coupled to the lighting/surface-cache engine and 4 miplevels were stored for each texture. There's more discussion of all of this in chapter 68 of Mike Abrash's Graphics Programming Black Book: http://www.jagregory.com/abrash-black-book/#chapter-68-quakes-lighting-model And software Quake's mipmap code is here: https://github.com/id-Software/Quake/blob/master/WinQuake/r_surf.c winquake's mipmapping was based purely upon the distance (and texinfo+screensize+d_mipcap).
on the other hand, opengl decides which mipmap to use based upon the rate of change of the texcoords - or in other words surfaces that slope away from the view are considered more 'distant' and thus get significantly worse mipmaps. you can work around that with anisotropic filtering, but that requires trilinear filtering in order to be well-defined (some drivers just bug out, some force it, some ignore it). This is a significant issue in FTE's software-esque rendering, and for now FTE uses only 3 mip levels to avoid the worst of it. note that the original/sw mipmaps retain their proper palette instead of being a blury mess, but this means that sloped surfaces like the side of health boxes just end up with about 4 random pixels or whatever. there's a few ways to work around this with recent glsl versions, but I've not tried to so so yet. tldr: glquake and winquake have _very_ different mipmapping rules, and glquake just looks blury in about every way possible... i prefer GL_NEAREST and gl_texture_anisotropy 8
that way it still looks pixely but less glitter at the distance. ...that in hardware accelerated versions of Quake, mipmap level selection is not normally something that the programmer has control over; this is done by fixed function components in the graphics hardware.
basically the video shows
game custom timedemo demo2 host error: progs/player.mdl not found q{tab} crash reload game custom exec config.cfg timedemo demo2 host error: progs/player.mdl not found game id1 crash I reproduced the crash here on windows with the 32 bit QS build, so it's indeed just those 2 config files that are doing it. thanks, will investigate.
...that in hardware accelerated versions of Quake, mipmap level selection is not normally something that the programmer has control over; this is done by fixed function components in the graphics hardware.
Looks like it was first exposed to the programmer with textureLod in GLSL 1.30 / OpenGL 3? https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/textureLod.xhtml You could probably brute-force it on older hardware by storing each miplevel as a separate texture. Performance would be horrible though.
Supersampling makes unfiltered textures look gorgeous and not flicker at all. Consider adding such an option.
https://imgur.com/a/jumoZ Up close or far away?
The thing about far way textures sparking is that it's basic mathematics. You have one pixel on the screen, and when the texture is sampled - either via nearest or linear, doesn't matter which - you're sampling more texels than will fit in that one pixel. Then when the scene shifts a little (like with regular Quake idle movement, or water warping, or whatever) the texels being sampled jump around. This is basic sampling theory stuff; it shouldn't be necessary to explain it, it's been mathematically proven for donkey's years.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |