 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
hlbsp has licensing issues from its toolchain, and the hull size issues makes it generally unusable for quake anyway.
besides, lit files and (same-size) replacements provide all the same advantages and with well-defined compat fallbacks, and without shamblers ending up half-inside walls, and retains overbrights, just with more files (unfortunately). if really needed then the -bspxlit arg can be used to embed the lit files, and -notex can be used to force external/replacement textures using the same mechanism hlbsp uses for external textures (so should work in the same engines) including support for q1 or hl miptex from a texture wad. How To Make A Video In 45 Seconds Expending No Effort
0. Do once: Install XVID codec 11 MB. This isn't about the codec, this is about something that works quickly and doesn't come with ads/spyware. 1. Go to a map. 2. Type record thisdemo 3. Walk around for 30 seconds. 4. Type stop to end demo recording. 5. Type capturedemo thisdemo Your are done. Where is thisdemo.avi? Type folder and it will be highlighted in Windows Explorer. 6. Optional: Drag and drop it on your YouTube page and upload it. If you are in 640 x 480 windowed mode when typing capturedemo it will be faster than say fullscreen resolution @ 1400 x 900 because 640 x 480 has far less pixels to encode than 1400 x 900. "Anyone else using Windows 10 have issues with the engine? "
Not so much in MarkV; but QArack, and JoeQuake specifically take 10 to 15 seconds to initialize in win 10 for me. Where as both engines take under 5 seconds on my XP and win7 machines. Dunno. opengl 1.x emulation? I can confirm that startup on Windows 10 is extremely slow on my new tower. I have an Intel 7820 and 32Gbs of RAM. HD is a pretty decent raid from 10,000 RPM drives. Videocard is a Nivida GTX 780.
In Windows 7 - a much older machine startup is near instantaneous. No audio issues as I have seen on my laptop thankfully. Is there any way I can help observe/record the startup issue for you? 1. Is it just the Direct X version?
2. Or is it also true for the WinQuake version also? 3. What about the SDL alternate build? download It might help me triangulate in on something. I'll test this evening and post results. I probably should have done a proper test.
Also a question about Dx9 files you have linked? How do I determine if I need those? Sorry yes I was setting up TB2 and only played around with the DirectX version as well as QS and QSS. I'll copy over the SDL alternate and WinQuake versions this evening.
> How do I determine if I need those?
Great question! Mfx said he had the issue and said installing those files solved it, but I'm not seeing a description of the message other than "it didn't start up". Posts 2106, 2109, 2110 -- "mfx - Thx, that download helped, works now." Yeah Mark V needs the DirectX 9 runtime support. I don't remember the error message but IIRC it's fairly obvious if that's why it's failing to start.
If you play other games on your computer there's a good chance you already have this installed. If not, it's harmless to install it. In the future, I may try to roll DX9 detection/installation into the installer form of the engine distribution.
There will of course always be the plain zips of the engine Report on Mark V Windows 10 delayed launch (and exit)
Mark V 1099r4 delay of 3-6 seconds launching and exit. mark_v_sdl_gl_gcc - no delay mark_v_winquake - no dleay mark_v_winquake_gl - no delay quakespasm quakespasm-spiked-win64 - short delay launching and exiting (1-2 seconds) Mark V 1099r4 has the longest pause of all exes. So DirectX Mark V is 3-6 seconds slower starting/exiting. Quakespasm is 1-2 seconds slower starting/exiting.
But Mark V WinQuake, SDL and OpenGL are unaffected. Trying to unravel that It is possible that specifying a refresh rate on startup slows things down. Quakespasm does this. DirectX Mark V specifies a refresh rate that is the desktop default when requesting fullscreen mode. The Mark V WinQuake/SDL/OpenGL doesn't touch refresh rate. If I am right Does the following have a difference in start up times a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX b) c:/quake/mark_v.exe -current // DirectX If it relates to the refresh rate, according to the code it looks like in windowed mode that Mark V DirectX does not set a refresh rate, but for fullscreen mode it does. /A guess. If this thought turns out not to lead anywhere and it may not, I have a couple of other thoughts but this best matches your test results Let me know If a 6 second delay is a problem, my engine is fucked.
But yeah, it's always nice to eliminate unnecessary delays. A delay at startup does sound like it's changing the display mode for sure; that would certainly do it.
Some info on command-line params used and resolutions of the PCs being compared would help a little more here. @baker I need to try this in windowed mode too. But I'll try what you posted above. Typically I stick to fullscreen.
One other thing that might help. Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV. The tools compile quickly as expected, then there's the delay in launching MV. Then I review the compiled map. Now for whatever reason after I quit MV the cmd windows (which has been running in the bg as usual) stays up for about 3-4 seconds before closing. I am 99% sure the delay in launching MV happens if I click a shortcut on the desktop without running any compilation so maybe unrelated? @mh Just remember this is Windows 10 now. My older machine is Win7 and had zero issues on start up and shut down with the same monitor and a very similar video card and same MV version. Also the same command line etc. 1920x1080 144Hz refresh forced by nvidia cp and that's my desktop res and refresh as well so I don't think it's mode switching. I need to confirm but I'm pretty sure the delay happened before I set the refresh in nvidia to 144Hz parms are +developer 1 and +gl_clear 1 +load map <map I am editing> (those were the same on other systems) Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV.
Windows programs inherits the CPU affinity and the process priority of the process that launches them. If the launcher is e.g. a single-threaded 32-bit program running at low priority, maybe Mark V needs some extra time to adjust its process' properties. Just a guess. Home and testing this now. We're getting somewhere.
Does the following have a difference in start up times a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX b) c:/quake/mark_v.exe -current // DirectX No delay on the windowed setting above! Fires right up. Also I have QS and QSS in the same forectory of MarkV so they share config.cfg. I'm noticing if I switch between those two the delay in launching and closing them goes away. If I launch MV then QS or QSS afterward the delay on those two is back. Albiet shorter as I said above. Can you confirm there is never a delay for windowed mode?
If so, that would be convincing enough evidence to make a test "fix" for DX9 fullscreen mode. /Probably throwing in a pq_moveup bug-fix that PoorChop spotted. @dumptruck, fifth + anyone else who experiences a delay on DX9 Mark V startup:
Download: DX9 Mark V - July 11 potential slow startup fix @dumptruck -- let me know! So this July 11 version no change.
Made 2 shortcuts on my desktop to this new exe. Windowed mode launched 5 times in a row with almost no delay. Using fullscreen (-current) re-introduced the delay. I launched this 5 times as well - all the same. The I switched between the two shortcuts twice. Same results. I tried this new exe on my older Win7 machine and it doesn't have the issue. Launches full screen with only a tiny delay. As I said, that is almost certainly a display mode change. Probably 2, switching away from your desktop mode then switching to whatever your selected mode is.
Check your console output log and you should see evidence of it. A bunch of vid_describemodes and vid_describecurrentmode commands can also help. Yes. I'm aware of the fact that it happens on 10 vs 7, but the fact that it doesn't happen in windowed modes is additional evidence. Great! You might also check and see if the fix eliminates the need to set the refresh Hz in the Nvidia control panel for your 144hz display.
It may resolve that, then again it may not. /I think dumptruck has easily earned the June and July "Gunter Award For High Quality Beta Testing".
Nothing is less fun with engine coding than issues that require setups not easily available. Thanks for the high quality beta testing that identified the source of this issue! Thanks I am no Gunter tho.
Did you misunderstand though? This did new release not fix the issue. :(
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |