 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I can reproduce it now - the key is launching the engine through the "Run Tool" feature in TB.
If I launch it through TB's "Launch Engine" feature, it works normally. So that might be the workaround to look at; in the "Launch Engine" dialog it says you can use variables to refer to the map name. Still weird that SDL1.2 works when launched via "run tool" and SDL2 fails, I will look into why that is the case. seems like its not a specific QS bug, but my 'custom' folder has my Qrack config, and trying to exec my autoexec.cfg QS runs into many keys and cvars that it doesnt recognise. Now, thats when things get weird. It will read the whole config, then if i type timedemo demo2 it says it cant find progs/player.mdl even though using the path command it finds id1. then pressing q then tab it fails at Q_strncmp strings not equal. So, my only assumption is that reading a config full of unknown cvars is polluting a string buffer.
again probably not a QS specific bug. Using a clean config i get no errors. http://quakeone.com/qrack/dev/autoexec.cfg
this isnt the actual cfg (not at home atm) but its still should be close enough 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
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |