The online racing simulator
TEST PATCH 0.6H2 (now H11)
(391 posts, closed, started )
Quote from troy :Yes, running H6 (On Win10)

Thanks. This is a bit puzzling. How does LFS look when you ALT+TAB out of it from full screen? Is it just a name and and icon in the taskbar?

If anyone can intercept and log the Windows messages sent to LFS in this situation in Windows 10, that would be interesting.

Quote from Flame CZE :In H6 when I select a custom engine sound or a layout to load/save, the background of the unselected buttons changes to dark. Is it a bug or a feature? It looks better either way Cool

That is a feature of the file loading dialog. I didn't write it with engine sounds in mind, more for the track editor. As you start to type a word, the matching files are highlighted and that can be helpful when loading a file from a large directory.

As you are on Windows 10...

Does your lag when entering the pits seem to be solved now?

Do you get the same issues as troy and mbutcher, ALT+TAB from full-screen results in high CPU/GPU usage? If paused when I do that, mine goes to zero CPU.
On my Windows 10 laptop (with Intel HD4000 graphics) I don't get any lag when jumping to the pits with H6. I do have the high CPU/GPU usage when alt-tabbed from full-screen, even when LFS is just sitting on the title screen. The thumbnail that comes up when I mouse over LFS on the taskbar is black when alt-tabbed, and contains whatever was last displayed in LFS when minimized from windowed mode.
Quote from Scawen :
Thanks. This is a bit puzzling. How does LFS look when you ALT+TAB out of it from full screen? Is it just a name and and icon in the taskbar?

If anyone can intercept and log the Windows messages sent to LFS in this situation in Windows 10, that would be interesting.

I also get increased CPU usage. It looks as its inactive in taskbar.

Here are the messages that I've logged while ALT+TABing from full screen (Programmed it to only log messages while I'm holding ALT key)



First number is time(0), then message name, wParam and lParam.
Attached images
Capture.JPG
Quote from Scawen :
Quote from troy :Yes, running H6 (On Win10)

Thanks. This is a bit puzzling. How does LFS look when you ALT+TAB out of it from full screen? Is it just a name and and icon in the taskbar?

If anyone can intercept and log the Windows messages sent to LFS in this situation in Windows 10, that would be interesting.

Sorry, don't know how to capture messages sent to LFS, but here is a screenshot on how LFS looks for me when I alt-tab. If you give me somewhere to start I'll be happy to try to capture something.
Attached images
lfstabbed.jpg
Quote from Scawen :Does your lag when entering the pits seem to be solved now?

Yes, the lag is gone now in H6, thanks. Thumbs up
Quote from Scawen :Do you get the same issues as troy and mbutcher, ALT+TAB from full-screen results in high CPU/GPU usage? If paused when I do that, mine goes to zero CPU.

Yes, when in game I get around 20% CPU and GPU usage, but when I Alt+Tab out of the game, it increases a lot.
Attached images
cpu.png
gpu.png
Well now i have been enjoying the new improved performance, and with the new frame graph something just seem so obvious now.

And that is the answer to this Q?:
Why is it I can reduce quality options and resolution and get 6-700 FPS!! and when i put on V-sync i still get temporal randomly stuttering??

Answer:
Well with the new frame graph when (display refresh rate@50HZ) it is showing every frame with 2 physics calculations until stutter begins then there could be one frame with one physics cal and next have 3 cals and so on randomly.
I am pretty sure it is the physics clock and display refresh rate going of sync for a moment. And when looking at picture with v.sync off and LFS FPS limit to 50 FPS i can see one screen tear relative steady but moving slowly up or down representing the two clocks difference. And i can also see that there is a fast jitter in the tear position of 20-30 pixels up and down representing the the jitter between the two clocks.
Now.. whenever this screen tear(with v-syn off) is in the middle of the screen and i turn on v-sync, everything is perfectly smooth always. But if the screen tear(with v-sync off) is at the upper or lower end of the screen and i turn on v-sync i get a terrible stutter, which make sense because the Frames change fast from 1,2 and 3 physics cal per frame because of the clocks "edges" overtake each other randomly. I hope you understand what i mean :-).

And what use is High frame rates when frames come randomly with bad timing(stutter) which ruin the illusion of the virtual world?

So, my idea or question to you Scawen: Why not sync the physics clock to the Refresh clock when v.sync is on?

And sorry if my lack of insight make you feel tired of getting this question Shy

It "just" need to micro(0,01Hz) adjust the physic clock to keep sync steady and aligned so the jitter between the clocks don't generate the stuttering. Its not like the physics clock is(or need to be) more precise than the refresh rate is it? This would be a major improvement in smoothness/anti-stutter without screen tear at all refresh rates and HW without having to make a complete "resample/interpolation" implementation.

I made this table just to see how often the Physics clock could be synchronized with different refresh rates
Refresh rate(HZ) ,number of Phys between sync, number of frames between sync
50Hz ,2 phys calcs between sync ,1 frames between sync
60Hz ,5 phys calcs between sync ,3 frames between sync
75Hz ,4 phys calcs between sync ,3 frames between sync
90Hz ,10 phys calcs between sync ,9 frames between sync
100Hz ,1 phys calcs between sync ,1 frames between sync
120Hz ,5 phys calcs between sync ,6 frames between sync

Of cause micro stutter at anything else than 50 and 100Hz will still occur but, it is really not as big a problem as the other stutter, created by the jitter and off sync clocks, is imo.

You probably have a good reason why its not already in-sync, and maybe it has already been tried but found not possible. I just wanted to know if this idea have been considered? Also now when you have made this frame info graph which seems to have all the info needed to update a physics clock to be in sync with refresh rate. I could be wrong Cool
Quote from Scawen :
As you are on Windows 10...

Does your lag when entering the pits seem to be solved now?

The shift+p lag happened in Win 8.1 as well, but it seems to be fixed in H6

However, I have noticed similar lag (for a shorter time maybe?) happening when exiting replays and when the multiplayer server list finishes loading.
This happens in H5 & H6, but not in H4.
When exiting a replay, it happens only when the frame limiter is on, the server list doesn't seem to matter if a frame limit is on or not.

It seems odd to me that it would happen in the server list, but it does seem to be a genuine hang (rather than waiting for a host to respond) because it never pauses in H4, but in H5/6 windows again briefly detects that LFS is not responding sometimes.
Thank you all for the feedback.

Quote from DANIEL-CRO :Here are the messages that I've logged while ALT+TABing from full screen (Programmed it to only log messages while I'm holding ALT key)

Interesting, your WM_ACTIVATE contains no minimised flag. Also there is no WM_SIZE, so LFS doesn't know about the resize. But I see there is a WM_WINDOWPOSCHANGED (that LFS ignores) and maybe that is the key. The documentation says that WM_SIZE is not sent if WM_WINDOWPOSCHANGED is processed. But it looks like in Windows 10 WM_SIZE is not sent in this case, even if WM_WINDOWPOSCHANGED is *not* processed.

In Windows 7 it's quite different:

Aug 11 10:54:51 WM_CANCELMODE
Aug 11 10:54:52 WM_DISPLAYCHANGE
Aug 11 10:54:52 WM_ACTIVATEAPP
Aug 11 10:54:52 WM_PAINT
Aug 11 10:54:52 WM_NCACTIVATE
Aug 11 10:54:52 WM_ACTIVATE - WA_INACTIVE - minimized 32
Aug 11 10:54:52 WM_ACTIVATEAPP

I suppose when you ALT+TAB in Windows 10, it's more like a resize, not a minimise. Looking at the screen shots, instead of vanishing to the task bar, there seems to be a small LFS window there. Ideally, should it be that little window stays live and keep showing a moving LFS, instead of a black screen? Is that the Windows 10 way?

Quote from hetner :You probably have a good reason why its not already in-sync, and maybe it has already been tried but found not possible. I just wanted to know if this idea have been considered?

Good thoughts you had there and it all makes sense. No, I have not considered this properly, but I'll consider it a bit. I'm not sure how easy it really is to do in offline mode. It is obviously complicated by the variety of refresh rates and the varying pattern of the number of physics updates per frame required to stay in sync. It would need to 'loosely synchronise' with the refresh rate so that for example if a refresh was missed it could catch up with real time. There is an additional complication online, as there are micro adjustments to the local game clock to stay in sync with the game clock on the server. I see some complication in trying to make micro adjustments to stay in sync with the monitor refresh rate while also making conflicting adjustments to stay in sync with the server clock. I'll consider this more but it might be too much to rush in for this week as I want to get that full version out this weekend.

Quote from Degats :The shift+p lag happened in Win 8.1 as well, but it seems to be fixed in H6

However, I have noticed similar lag (for a shorter time maybe?) happening when exiting replays and when the multiplayer server list finishes loading.
This happens in H5 & H6, but not in H4.
When exiting a replay, it happens only when the frame limiter is on, the server list doesn't seem to matter if a frame limit is on or not.

It seems odd to me that it would happen in the server list, but it does seem to be a genuine hang (rather than waiting for a host to respond) because it never pauses in H4, but in H5/6 windows again briefly detects that LFS is not responding sometimes.

Well that is a bit too strange that the SHIFT+P is fixed but those other cases are not!

Exiting from a replay should be the same as "game to pits" or "game to lobby". The end of the search for the list of hosts is another case of moving from a higher frame rate to a lower one. List of hosts, while creating the list, has a higher frame rate than all the other entry screens.

There is one more fix I can try, simply resetting the timing frame counter any time the frame rate limiter changes. But I prefer to understand the problem first so this requires some more thought.
Quote from Scawen :Is that the Windows 10 way?

I use windows 10 and H6
with vsync on full screen all okay alt tab makes screen black.
going to window mode vsync goes off alt tab still displays game.
going full screen again vsync is on again.

so only window mode vsync goes off here.
Quote from Scawen :
I suppose when you ALT+TAB in Windows 10, it's more like a resize, not a minimise. Looking at the screen shots, instead of vanishing to the task bar, there seems to be a small LFS window there. Ideally, should it be that little window stays live and keep showing a moving LFS, instead of a black screen? Is that the Windows 10 way?

I would say that would be the preferred way, keep vsync on and let it run in the preview window. Take Assetto Corsa for example it already does that. I know of some other software that keeps playing in those preview windows, like VLC for example.

But I'm just a consumer so I don't know how software is supposed to behave in this case, I just know it's neat when something moves in the previews. Big grin
Attached images
acwin10.jpg
Quote from Scawen :
Quote from hetner :You probably have a good reason why its not already in-sync, and maybe it has already been tried but found not possible. I just wanted to know if this idea have been considered?

Good thoughts you had there and it all makes sense. No, I have not considered this properly, but I'll consider it a bit. I'm not sure how easy it really is to do in offline mode. It is obviously complicated by the variety of refresh rates and the varying pattern of the number of physics updates per frame required to stay in sync. It would need to 'loosely synchronise' with the refresh rate so that for example if a refresh was missed it could catch up with real time. There is an additional complication online, as there are micro adjustments to the local game clock to stay in sync with the game clock on the server. I see some complication in trying to make micro adjustments to stay in sync with the monitor refresh rate while also making conflicting adjustments to stay in sync with the server clock. I'll consider this more but it might be too much to rush in for this week as I want to get that full version out this weekend.

Just thinking out loud.. please ignore me if not relevant.Smile
If a hard clock-locking approach(not micro adjusting) is an option then dropping or adding one frame once in a while to be in sync with Server time is not really an issue because one frame time error say every more than 10sec is hardly detected by the eyes, its when a stream of error occurs it really appear as stutter to the eyes, imo. So ideal online the game clock should be keept aligned so that the jitter don't cause stutter and if possible frames should be dropped or added when needed to be in sync with online server. Just like video capture programs do when syncronizing to a VCR frame clock to keep Video and Audio in sync throughout the capture, which is usually 25FPS and go completly unnoticed by most people :-)

At 50Hs refresh rate offline the sequence would look like this:
<wait for next V-sync>
<wait(5ms)> // wait to align edges from colliding because of jitter
<DoGameCalc>
<wait((10ms)-(timetoDoGameCalc))>
<DoGameCalc>
<start sequence over>// aproximatly 20-15=5ms to next v-sync and 10ms to next DoGameCalc

At 60Hs refresh rate offline the sequence would look like this:
<wait for next V-sync>
<wait(5ms)>
<DoGameCalc>
<wait((10ms)-(timetoDoGameCalc))>
<DoGameCalc>
<wait((10ms)-(timetoDoGameCalc))>
<DoGameCalc>
<wait((10ms)-(timetoDoGameCalc))>
<DoGameCalc>
<wait((10ms)-(timetoDoGameCalc))>
<DoGameCalc>
<start sequence over>// aproximatly (3*(1000/60))-(5+(4*10))=5ms to next v-sync and 10ms to next DoGameCalc

At 50Hs refresh rate the psuedo code for frame adding/dropping would look like this:
<wait for next V-sync>
IF (Serverclockdif>=max_time_behind)
{ /*Drop video frame*/
<wait(4ms)>
<DoGameCalc>
<wait((6ms)-(timetoDoGameCalc))>
<DoGameCalc>
<wait((7ms)-(timetoDoGameCalc))>
<DoGameCalc>
<start sequence over>// aproximatly 20-(4+6+7)=3ms to next v-sync and 8ms to next DoGameCalc
}
else
IF (ServerclockDif<=max_time_ahead)
{ /*Add video frame*/
<wait(10ms)>
<DoGameCalc>
<start sequence over>// aproximatly 20-10=10ms to next v-sync and 15ms to next DoGameCalc
}
else
<wait(5ms)>
<DoGameCalc>
<wait((10ms)-(timetoDoGameCalc))>
<DoGameCalc>
<start sequence over>

ofcause it will be more complicated with other refresh rates, put if the game clock can accept momentary jitter of max +/- 5ms then I beleave this approach could work.. Maybe some longer and more complexe sequences can be made to optimize jitter. Else I find it hard to solve the sync to both server and refresh rate at the same time Cool, then resample/interpolate is the only optionUhmm
Quote from DANIEL-CRO :I also get increased CPU usage. It looks as its inactive in taskbar.

Some possibilities of solutions for this problem require D3D9Ex. Did you find out why your deb.log showed only D3D9? I added an extra error message in deb.log for the case where D3D9Ex appears to be available in the DLL but fails to start.

Quote from troy :I just know it's neat when something moves in the previews. Big grin

I agree! Smile
Updated to H6 and fullscreen v-sync now works like it should on wine/OSX.
Quote from Scawen :
Interesting, your WM_ACTIVATE contains no minimised flag. Also there is no WM_SIZE, so LFS doesn't know about the resize. But I see there is a WM_WINDOWPOSCHANGED (that LFS ignores) and maybe that is the key. The documentation says that WM_SIZE is not sent if WM_WINDOWPOSCHANGED is processed. But it looks like in Windows 10 WM_SIZE is not sent in this case, even if WM_WINDOWPOSCHANGED is *not* processed.

In Windows 7 it's quite different:

Aug 11 10:54:51 WM_CANCELMODE
Aug 11 10:54:52 WM_DISPLAYCHANGE
Aug 11 10:54:52 WM_ACTIVATEAPP
Aug 11 10:54:52 WM_PAINT
Aug 11 10:54:52 WM_NCACTIVATE
Aug 11 10:54:52 WM_ACTIVATE - WA_INACTIVE - minimized 32
Aug 11 10:54:52 WM_ACTIVATEAPP

I suppose when you ALT+TAB in Windows 10, it's more like a resize, not a minimise. Looking at the screen shots, instead of vanishing to the task bar, there seems to be a small LFS window there. Ideally, should it be that little window stays live and keep showing a moving LFS, instead of a black screen? Is that the Windows 10 way?

Improved my program a bit since last night Smile
Now it shows all data sent with WM_WINDOWPOSCHANGED/ING as well as I called IsMinimized/IsIconic on each log which could be simple solution.



Quote from Scawen :
Some possibilities of solutions for this problem require D3D9Ex. Did you find out why your deb.log showed only D3D9? I added an extra error message in deb.log for the case where D3D9Ex appears to be available in the DLL but fails to start.

Seems like the cause of this on my computer was d3d9.dll in LFS directory. I don't remember changing it for long time, not sure how (if) D3D9Ex worked on Win7? Anyway that d3d9 didn't have any purpose so I removed it.
However I didn't see any error message ...
Spoiler - click to revealAug 11 20:29:57 LFS : 0.6H6
Aug 11 20:29:57 timer resolution 1 ms
Aug 11 20:29:57 read config
Aug 11 20:29:57 get command line
Aug 11 20:29:57 preinit d3d
Aug 11 20:29:57 started Direct3D 9
Aug 11 20:29:57 number of adapters : 1
Aug 11 20:29:57 adapter 0 - valid modes : 102
Aug 11 20:29:57 load font
Aug 11 20:29:57 -----
Aug 11 20:29:58 max texture size 16384
Aug 11 20:29:58 can do shadows
Aug 11 20:29:58 can use 2x tex
Aug 11 20:29:58 can do multi tex
Aug 11 20:29:58 create english file
Aug 11 20:29:58 kb : Central Europe
Aug 11 20:29:58 initialisations
Aug 11 20:29:58 human system
Aug 11 20:29:58 tables
Aug 11 20:29:58 helmet
Aug 11 20:29:58 controllers
Aug 11 20:29:58 Controller 1 (Generic USB Joystick ) :
Aug 11 20:29:58 Added 5 axes
Aug 11 20:29:58 load objects
Aug 11 20:29:58 start intro
Aug 11 20:29:58 end of initialisation
Aug 11 20:29:58 init sound
Aug 11 20:29:58 Controller 1 (Generic USB Joystick ) :
Aug 11 20:29:58 Added 5 axes
Attached images
2.JPG
OK, Windows 10 users, please can you see if this solves your issues, before I update the first post.

Changes from 0.6H6 to 0.6H7

Misc :

Z-buffer depth setting can now be changed without restarting LFS
Reduced some of the Z-buffer issues when using a 16 bit Z-buffer
More updated translations - Thank you translators!

Fixes for Windows 10 :

High CPU/GPU on ALT+TAB from full screen with vsync in Windows 10
Pause when exiting from replay or reaching end of List of Hosts


EDIT : 0.6H7 download links removed, thanks for the testing.

0.6H10 with Windows 10 fixes : https://www.lfs.net/forum/thread/87997
Quote from Matrixi :Updated to H6 and fullscreen v-sync now works like it should on wine/OSX.

Thanks, good to know, though I don't know what I changed! Big grin

Quote from DANIEL-CRO :Improved my program a bit since last night Smile
Now it shows all data sent with WM_WINDOWPOSCHANGED/ING as well as I called IsMinimized/IsIconic on each log which could be simple solution.

Good stuff, thanks a lot for that.

H7 takes note of WM_WINDOWPOSCHANGED and at that point sets LFS's 'minimised' variable if IsIconic returns true. The hope is this will catch the ALT+TAB in Windows 10 which doesn't seem to send WM_ACTIVATE during ALT+TAB.

Quote from DANIEL-CRO :However I didn't see any error message ...

When there is no error message, that means that the function to initialise DirectX 9Ex is not even found in the DLL. That normally means Windows XP, so that's not an error.
Sorry, didn't seem to fix the high cpu/gpu usage, at least on my system.
Neither here Frown

BTW it doesn't matter if VSYNC/frame limiter is on or off. Increased CPU usage is there regardless of settings.
Very frustrating.

In the code for WM_WINDOWPOSCHANGED I have:
minimised = IsIconic(hWnd);

In the code for WM_ACTIVATE I have:
minimised = HIWORD(wParam) ? 1 : 0;

And it should not try to draw anything when that variable is set. This simple mechanism works in Windows 7.

But Daniel's last post makes me want to ask a few more questions. To be clear, is this only when you ALT+TAB from full screen? What happens when you just click the minimise button on an LFS window? In that case does your CPU usage go low? Also, in the case of high CPU usage, is the GPU usage also high in H7?
Too me it happens only when i alt tab when windowed and minimize gpu goes 0% useage.
In full screen, using ALT+TAB to switch to the desktop with LFS running results in both higher CPU and GPU usage. In windowed mode CPU and GPU usage go down as expected when one minimizes LFS.
Have any of you tried what hapens if you switch the virtual desktop in Windows 10? That might be something to take account as well.
For Windows 10 Users
For Windows 10 users, here is a patch (exe only) with some message logging.

I would like to try and understand how that minimised variable is being set or not being set.

The logging goes to the file deb.log

To keep the log small, please can you try these steps:

- Run LFS
- Go full screen if it wasn't already
- ALT+TAB to minimise LFS
- At this point, wait approx 5-10 seconds so we see a time gap in the log. Maybe have a look to check that LFS is using high CPU / GPU.
- Click on the LFS icon to restore it to full screen
- ALT+F4 to exit LFS
- rename deb.log to deb.txt so you can upload it here. Mine is attached with some notes added.

http://www.lfs.net/file_lfs.php?name=LFS_6H8_EXE.zip
Attached files
deb.txt - 2.9 KB - 103 views
If I check the deb.log in my own LFS folder, it stops logging after the initialisation for some reason (see deb1.txt).
When I try it with original LFS install, it logs correctly (deb2.txt).

GPU usage around 80% when minimised, 10% when in LFS.
Attached files
deb2.txt - 2.7 KB - 108 views
deb1.txt - 1.6 KB - 92 views
This thread is closed

TEST PATCH 0.6H2 (now H11)
(391 posts, closed, started )
FGED GREDG RDFGDR GSFDG