The online racing simulator
TEST PATCH 0.6H2 (now H11)
(391 posts, closed, started )
Quote from DANIEL-CRO :BTW Scawen, now that our FPS increased so much I guess we are ready for some decrease (read: graphics improvements) Big grin

Shadow mapping ? Realtime reflections ? PCSS ? Motion blur ? Scawen, please tell me that your to-do list is full of good things like that (yep, I'm definitly crazy). Big grin
Quote from DANIEL-CRO :
Quote from hetner :
Ofcause it would not be a backward compatible solution and therefore out of scope for now(until new physics maybe). But i cant see why 8.333ms step should be any different from 10ms to handle?Uhmm

ATM is simply checks if checkpoint has been crossed in last physics update.

I still dont see why checkpoint should be limited to 1ms resolution.
Quote from DANIEL-CRO :
Quote from hetner :i think maybe it is using highperformance timing which have much better resolution than 1ms. It could be based on QueryPerformanceFrequency and QueryPerformanceCounter calls which usually have better than ~500ns resolution or the intrinsic instruction RDTSCP which have the resolution of your CPU clock(theoretically a 3GHz would have 333,333ps resolution)

These timers have nothing to do with LFS time. They are mostly only used to measure time needed to complete some tasks (parts of code).

Ok maybe you have some insight i dont have, but it was just to say that there is lots of Timing resolution in computers today so to make a 8,333ms clock with same accuracy as a 10ms should not be a problem. But ofcause it depend on how the implementation is now if its an easy task to change or not.
But to be honest i think the best thing to do is to find the most optimal clock for physics and then solve the graphics smoothness by interpolation/resampling, this would also give a steady input lag.

Quote from DANIEL-CRO :
Quote from hetner :Usually Sleep(1) take less than 1ms Uhmm typically 0,98ish ms if i recall correctly. maybe you forgot to take your performance timers calls overhead into account??

None of my tests confirmed that ... Yesterdays tests were done in other Project which run tenths of other threads very light in fact, but I'm sure it had some effect on final results. Todays results are even better. Overhead is really low in this case as you can see in table below. 1000 samples for each.

Hmm well it could be your computer and mine is different, or i could remembering wrong, but i am pretty sure i both read it and measured it on my PCs a while back where i was coding some usec-timing software at work. But i cant seem to find anything about it now though Schwitz
@Scawen, I found a mistake on Fern Bay. The wall is in the air, but Z is 0. Can you add ground level check the for new objects or add option for -Z?
Quote from Amynue :https://developer.oculus.com/blog/upcoming-oculus-pc-sdk-0-7-compatibility-changes/

Thanks, they sent an information email about this. Our current official version will no longer work with the new Oculus runtime when it is released on 20th August. It seems to me the best plan for LFS is to finish the few remaining bugs and make the current version official as soon as possible, e.g. next week. Our Rift support in the test patch is based on Oculus 0.6, so it will work with the new runtime. Then I'll get on with the track shaders that can help Eric with the initial S3 tracks.

Quote from valiugera :@Scawen, I found a mistake on Fern Bay. The wall is in the air, but Z is 0. Can you add ground level check the for new objects or add option for -Z?

I had to make that decision, to disallow Z values below zero, in order to reach the highest altitudes at Westhill. The autocross object data is highly compressed, to allow them to be passed quickly to joining racers. There is only one byte in the object data for altitude, so it can't go below zero. There are very few places in LFS which are below zero so this is the best decision. Maybe in future the sutocross object size will be increased, allowing more flexibility.
I'm not sure if I'm the only one having this issue, and I hope that I'm posting in the correct area.

However, approaching the roundabout @Westhill (See screenshots below)



Look like there is nothing ahead but cars are visible.
PS. Please remove/move my post if this isn't the correct area.

Many Thanks.
Attached images
lfs_00000078.jpg
lfs_00000079.jpg
I believe that missing road has something to do with switching between paths. Seen this also before in different places,never in closed config track.
Quote from racerss :I'm not sure if I'm the only one having this issue, and I hope that I'm posting in the correct area.

However, approaching the roundabout @Westhill......

Saw this 'bug' while ago - HERE

Test Patch 0.6H6 is now available, with various fixes and some improvements. Thank you for the testing and feedback.

https://www.lfs.net/forum/thread/87997

Changes from 0.6H5 to 0.6H6

Misc :

Reduced min / max values for "Sound lag" setting - default now 0.08
Small error report added to deb.log if failed to start DirectX 9Ex
More efficient car distance sorting system for sound and graphics
More updated translations. Thank you translators.

Oculus Rift :

Updated ORDIRECT.dll to use 0.6.0.1 runtime instead of 0.6.0.0

Fixes :

CPU usage increased if minimised from full screen mode with vsync
Missing sound from nearby cars that were off screen in multiplayer
Frame rate limit system could cause lags when used in Windows 10
Frame info display could be clicked even when mouse was hidden
Virtual dashboard disappeared if another nearby car was drawn
Very good Sunday worker, as always Big grin

Quote from Scawen :...Then I'll get on with the track shaders that can help Eric with the initial S3 tracks...

do not hesitate to share some screenshots of these 'intial S3 tracks' when you think they can be shown to public eyes Big grin
thanks for the test patche work like a charm for me.

Quote from Flotch :Very good Sunday worker, as always Big grin

Quote from Scawen :...Then I'll get on with the track shaders that can help Eric with the initial S3 tracks...

do not hesitate to share some screenshots of these 'intial S3 tracks' when you think they can be shown to public eyes Big grin

and the experimental shadow/reflection/shaders system! we can't get enough of those!Petals
thanks Scawen, improvements are amazing. i hope s3 tracks without problems in specific curves. just in diferent places like a old tracks ( because Westhill is too large, we had us some problems with it ). the old Westhill will be integrated again? I miss the old track Smile .Westhill still with good detail and better FPS, continue with their excellent work Wink
Quote from Flotch :Very good Sunday worker, as always Big grin

Quote from Scawen :...Then I'll get on with the track shaders that can help Eric with the initial S3 tracks...

do not hesitate to share some screenshots of these 'intial S3 tracks' when you think they can be shown to public eyes Big grin

That would be a terrible idea, the community would eat them alive. (But, I'd still like to see it.) Also, I'd still be happy to pay for S3 right now. Considing the amount of joy S2 bought me, I feel like I owe you guys more money.
I think they should start teasing us with screenshots only 1-2 years before S3 release, not now.


Did a quick 10min test of new 0.6H6 under Ubuntu 15.04 + wine + notebook (gfx: Intel Sandybridge mobile or something like that). Only few laps on the WE karting track (longer one), till my touchpad got too hot to steer with a finger Big grin (as always).

Works at least as good as 0.6H, feels a tiny bit smoother, but I can't really see FPS improvements there (quite logical, would made more sense to do some benchmark over international track to get all the benefits of new code), also it's impossible to reliably measure anything on notebook in this hot weather without seriously preparing some benchmark environment (like fixed cpu/gpu clocks, etc.).

So just to let you know, that there is no obvious regression for me.
Quote from Ped7g :notebook (gfx: Intel Sandybridge mobile or something like that).

That not a name of a graphics processor. It's HD2000 or HD3000. Designed to accelerate Youtube and video files and thats about it. (Alright, exaggerated, but Intel does a poor job with their graphics "acceleration" business).
Quote from cargame.nl :Alright, exaggerated, but Intel does a poor job with their graphics "acceleration" business.

Have you heard about Broadwell desktop CPUs ? Big grin
Why not talk about Skylake? Just as realistic as this discussion.

https://en.wikipedia.org/wiki/Intel_HD_and_Iris_Graphics vs https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units => GFLOPS

Conclusion; rubbish.

It's nice that LFS seems to run on low end chips of Intel but don't expect world wonders. Therefore I do not get people which buy a laptop without looking what kind of processor power it has. Worst of all, complaining afterwards that it can't keep up. Ped7g wasn't complaining though, just making a conclusion that two times nothing still is nothing Wink

And I don't like it when people defend Intel by saying that they do a good job because they don't. It's about the same as saying that a Chevrolet Matiz 1.2 also is good enough compared to a VW Golf 2.0 or something. Good enough for city traffic but the highway is a different story. The Sims 3 = city... Wouldn't say LFS is highway but at least rural road Wink
Quote from cargame.nl :Why not talk about Skylake? Just as realistic as this discussion.

https://en.wikipedia.org/wiki/Intel_HD_and_Iris_Graphics vs https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units => GFLOPS

Conclusion; rubbish.

Actually Haswell's IGP is close to a GTX 750 and I can actually play LFS on my laptop with my HD5000 @ 1366x768 with constant 60 FPS with some cars and Westhill. Wink


Quote from cargame.nl :And I don't like it when people defend Intel by saying that they do a good job because they don't.

How can I defend Intel with recent Skylake announcement ? Big grin
IGP are nice for very light gaming (or LFS, which is really not using GPU), but it dosen't match a mid-end graphics end ATM.
Quote from Scawen :Fixes:

CPU usage increased if minimised from full screen mode with vsync

In W10, this is still happening, just to a lesser degree. In all cases that previously went to ~40%, it's now hitting ~20%.

Can anyone else replicate this behaviour in W10?
Quote from Scawen :Test Patch 0.6H6 is now available, with various fixes and some improvements. Thank you for the testing and feedback.

https://www.lfs.net/forum/thread/87997

Changes from 0.6H5 to 0.6H6


Fixes :

CPU usage increased if minimised from full screen mode with vsync

I've got the same thing happening but with GPU usage, somehow when I alt tab out of the game LFS "forgets" that vsync is on and runs without it, GPU usage is almost maxing out in this situation.
Quote from troy :I've got the same thing happening but with GPU usage, somehow when I alt tab out of the game LFS "forgets" that vsync is on and runs without it, GPU usage is almost maxing out in this situation.

Are you sure that you installed H6 correctly? Please check the version number at the bottom of your entry screen.

There was a very good reason for this going wrong in H5 but I really fixed that. LFS wasn't taking note of the 'minimised' information in the WM_ACTIVATE message. But now it does, and it doesn't draw anything at all when minimised now.

If that is still happening in Windows 10 with H6 then I can only think that that Windows 10 is not sending a correct WM_ACTIVATE message to LFS when it is minimised from ALT+TAB.
Yes, running H6 (On Win10)
Attached images
h6.JPG
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
Attached images
engine.png
I found myself surprised. After updating to H6 my game is running nearly 3 times as fast as before.

Well done once again, dev team.
This thread is closed

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