The online racing simulator
New Version 0.6F and Progress Report
(453 posts, started )
Quote from Scawen :Unlike some developers I will make sure you don't need this year's £1000 computer to run it.

Does that mean you will work on threading? Because we are now getting bound to a single core, while most modern CPU's benefit a LOT from threaded processes. I understand you want to give people on ancient PC's a good experience too, but you also have to give some love to modern systems IMO.
Does someone actually have fps issues or something with lfs being single threaded?
why is everyone thinking the program developers should make their code multithreaded, when it should be the duty of the os to distribute the load across the available cores? why is windows not able to just use all the processing and graphics power the machine is offering? i mean the days when programmers could direct adress hardware are long over with all that abstracting layers we have now, so there shold be a way windows is distributing a single tread program over more than one core - how is that anyways with hypertreading and virtual cores?

if there are people that own faster machines then lfs should give them the freedom to just use hi-res graphics and more that one screen with silly frame rates without forcing others do buy a new computer just to be able to play, so scalability of the graphics should be possible via hi-res texture mods.

but keep on the good work scavier - better to support a whole lot of middle class computers than to always just optimize for the latest and greatest.

peace, mo
Quote from cargame.nl :Earlier this week somebody joined public racing with a Pentium D, on-board graphics and he was doing 640x480 with ridiculously low FPS @start, like 10 FPS or something. He also was, not, joking.

I am not happy with those people, they cause more trouble then they realize themselves but what do you say to those people, fack off?

I would like to see some minimum requirement threshold myself but apparantly Scawen has a different philosophy about it and would like to support every toaster which exists on the planet.

Heh, it was me. I was playing on uncle computer I have 300+ FPS at home right now. Sometimes it didn't even load the start as he had a pretty bad connection that timed out sometimes. What was most important was that I was having fun
Quote :LFS performance needs are always increasing.

How much have they increased in the last, uhm, 9 years? Good optimization is one thing, graphics level is another.

Progress is not evil. People constantly upgrade their hardware, the question is whether to use the ever-growing computing power, or just sit and claim great support for old PC's and OS'. No offense.
Quote from BallWalk :Heh, it was me. I was playing on uncle computer I have 300+ FPS at home right now. Sometimes it didn't even load the start as he had a pretty bad connection that timed out sometimes. What was most important was that I was having fun

It was indeed you.. Doesn't matter, I've seen a lot of you's and the problem is that they all having fun. The other racers not however, bad connections and bad performing systems always lead to extremely poor racing most of the time with numerous crashes/accidents.

It happened during low server attendance so its not really a problem however that is not always the case (because LFS S2 is not entirely dead )

But eeehh.. I await the day that ping and FPS data is included in an InSim packet. Would be extramegasuperawesome.
There will be a testing period for new Westhill where we could report bugs etc., I suppose?
Reason why I'm asking is that current Westhill track has some of the side roads with the texture of tarmac, while grip of grass as well there is green dust coming from this parts. It could be fixed already, dunno. Just want to make sure


EDIT:
Quote from molocco :when it should be the duty of the os to distribute the load across the available cores? why is windows not able to just use all the processing and graphics power the machine is offering?

:ices_rofl
Quote from Scawen :... We expect to release this version for testing in a few weeks, ...

so, tomorrow, or just after, we are in the window (2x 1 week => 2 weeks)
Quote from Fox 2 :Progress is not evil. People constantly upgrade their hardware, the question is whether to use the ever-growing computing power, or just sit and claim great support for old PC's and OS'. No offense.

Yeah but I'm just not sitting here claiming anything. We still have plenty of complaints from people with reasonable hardware, how there are problems with frame rate on the start grid or at turn 1.

So, indeed, LFS shouldn't be made to run on a casio wristwatch from the 1980s. Neither should it require a Cray supercomputer to run it.

We have the balance about right at the moment and the graphical and physical requirements will gradually increase with the gradual increase in computer power.

It's so obvious, I feel silly saying it.

Quote from DANIEL-CRO :There will be a testing period for new Westhill where we could report bugs etc., I suppose?
Reason why I'm asking is that current Westhill track has some of the side roads with the texture of tarmac, while grip of grass as well there is green dust coming from this parts. It could be fixed already, dunno. Just want to make sure

Yes, there will be a period of public testing. The community will be divided during that period, so we will try to get it as good as possible before the public test. No doubt you will find some fixable issues.
/off
Scawen, I've found a small typo in the Oculus setup part of the 0.6F information page and in the Setup Instructions text on Oculus Share (here).
5. section, 2. paragraph, 2. sentence: "This mey be available when your desktop is set to extended..."

/on
Quote from MandulAA :/off
Scawen, I've found a small typo in the Oculus setup part of the 0.6F information page and in the Setup Instructions text on Oculus Share (here).
5. section, 2. paragraph, 2. sentence: "This mey be available when your desktop is set to extended..."

/on

Thanks! I have asked Victor to fix that and he probably will this evening. I will not update the Oculus site yet as it would have to go through another submission process, so I'll try to remember the next time I am updating something there.

Quote from 5tag :Scawen can you please have a look at my suggestion/question? I hope it's not too hard to code.

https://www.lfsforum.net/showt ... php?p=1860934#post1860934

Hi, I'm not sure about doing this as I don't think it would be good to race using cross-eyed view.

[For anyone who doesn't know about cross-eyed 3D viewing, it's where you have the right eye image on the left and the left eye image on the right, then you cross your eyes so each eye looks at the correct image. You then get a "small" 3d image. See attached double image in LX4 at South City]

I know cross-eyed view is a good way to get 3D from small images without any equipment, but I don't think it's a good idea for large images, or for extended periods of time. It might make your eyes go funny...

I think if you want to do low-cost 3D then the Anaglyph mode will be much better. You need red-cyan glasses to see it, and these cost only a few pence for basic ones. I've implemented a pixel shader to do this and it is working well. I should be able to release this in a couple of days, after I've cleaned up some of my code. See attached image in LX4 at Blackwood.
Attached images
LFS_SO_cross_eyed.jpg
LFS_BL_anaglyph.jpg
By the way, I made the cross-eyed image by manually swapping the images in an image editing program. The original image from LFS was side-by-side (full) 3D in conventional headset mode. But as LFS presents that, it is not suitable for cross-eyed viewing because the left eye view is on the left and the right eye view is on the right. Cross-eyed view requires the opposite.
Quote from DANIEL-CRO ::ices_rofl

why do you just rofl at my questions instead of sharing your superior knowledge whats so funny about thinking that it should indeed be the duty of the operating system to communicate between programs and the computer hardware?
if it wasn´t then we could have programs that directly boot the computer hardware to get rid of that os overhead and side problems like load balancing or security flaws...

peace, mo
Quote from bishtop :based on steams stats, which how many % dont and have never used steam so not a real comparision on actual total number ooutside steam.

Anyone know if Origin have stats for similar things

You know when they take polls, they usually ask around say 1500 people and give an error margin +-3% when they measure how the political parties are divided.

So when Steam has a userbase of over 65 million gamers, I'd say the stats are a very good indicator of the overall specs people game with.
Quote from molocco :why is everyone thinking the program developers should make their code multithreaded, when it should be the duty of the os to distribute the load across the available cores? why is windows not able to just use all the processing and graphics power the machine is offering? i mean the days when programmers could direct adress hardware are long over with all that abstracting layers we have now, so there shold be a way windows is distributing a single tread program over more than one core - how is that anyways with hypertreading and virtual cores?

I remember in the past when somehow multiple processors could speed up a computer running a single threaded program.

I don't really know how that worked but it doesn't work on modern CPUs, I guess because they are thinking ahead with their predictive branching and so on.

EDIT: The above info is wrong, multiple CPUs could never really speed up a single thread, all they could do is share some of the work that the original CPU was doing, which on older computers could be quite a lot. E.g. http://www.beebmaster.co.uk/SecondProcessors.html So the reason modern multi-core CPUs cannot speed up single threads is nothing to do with predictive branching. They just never could do anything except work on separate threads, leaving the other CPU less loaded.

So now, these "cores", which are basically multiple CPUs on a chip, must follow their own sections of code (threads) which are quite independent from each other. And so the only way to speed up a program on a multi core CPU is to split the code up into separate threads.

The obvious separation for LFS would be physics on one thread, graphics on another. The operating system can then run one thread on one core and the other thread on another core. It's quite a rewrite but as so many computers are dual core, this one seems like it would be quite a good idea. It's quite a change though, the physics system needs to provide a "snapshot" of the position and orientation of every object, so that the graphics renderer can render a picture of this snapshot while the physics system is generating the next frame.

Then it seems to me if you had things like dynamically changing weather, you could generate some of the effects on yet another thread, possibly doing those effects in more detail on a more powerful computer. That kind of thing would always be at a lower priority though. While dual cores are common, that would be the target, unless there were obvious tasks for a third core.
Quote from Scawen :I remember in the past when somehow multiple processors could speed up a computer running a single threaded program.

I don't really know how that worked but it doesn't work on modern CPUs, I guess because they are thinking ahead with their predictive branching and so on.

Somehow I doubt that

That thinking at runtime would take too much time to bring any improvements, perhaps it could be implemented into compiler, but that would bring only troubles because code wouldn't run the same way you wrote it, hard to debug...
I would like some links, references, ... on that.

Or did you mean Hyper Threading which is basically two virtual cores per one physical?
not gonna claim I understand all this, but interesting read : http://www.agner.org/optimize/microarchitecture.pdf

I doubt branch prediction works on multiple physical cores though, where branches would spread onto different cores. I'll bet it's more like a feature each core has to optimise code execution.
Quote from aaltomar :You know when they take polls, they usually ask around say 1500 people and give an error margin +-3% when they measure how the political parties are divided.

So when Steam has a userbase of over 65 million gamers, I'd say the stats are a very good indicator of the overall specs people game with.

7.3 million users max online on avg on any given day which is 7.3 that like using steam and how many are duplicate accounts held by banned users ect and there are a lot more that dont use it

and hi victor how are you
I do not understand the area of programming, but I follow this topic, and something that I despertor interest is the possibility to participate in the development of the new Westhill Circuit, would be a joy for me to participate in it.

Total excitement here in Brazil for new updates LFS * --- *

sorry for English, translated by google translator hehehehe

Quote from Scawen :Then it seems to me if you had things like dynamically changing weather, you could generate some of the effects on yet another thread

DirectX 9 has a limitation in multi-threaded mode in that only a single thread can safely access the DX device context at any one time. (DX11 provides an alternative thread-safe mechanism).

To counter this MS recommends using some form of synchronisation, but personally I prefer to take a more model/controller/view approach to my internal architecture, although I know LFS isn't OO internally and I get the impression the internal workings are quite highly coupled - so I think it's going to be a fairly heavy job isolate component parts and put them to threads.
Quote from Scawen :Which bit did you doubt?

Branch prediction: http://en.wikipedia.org/wiki/Branch_predictor

Well, thats not exactly like multithreading as far as I can tell.

You see that Vic doubt too

Anyway lets not go too much offtopic. Idea of separating physics and graphics to separate threads seems nice.
My assumption is that physics is much lighter in the current LFS than graphics, like I mentioned few days ago.
With the current state not sure it will help much, perhaps it will on PCs that are struggling to run LFS, but definitely will be nice to have VSYNC on and physics (inputs/outputs) constantly run at 100Hz.
Perhaps you could gain some info how much % time LFS spend in physics calculation, how much in graphics, ... so we could get more idea about possible performance increase. Of course that depend on grid size and graphics settings a lot.

By test I've done FPS on start grid is mostly hurt by cars themself. By lowering LOD you easily double FPS, however making cars look like ghosts is not an option for most.
Why cars are so hard to render? Are there any possible optimisations? Is it possible to do some multithreading there? :P (Becky?)

Are there any hints that new tyre physics will use much more CPU, so transition to separate physics/graphics makes more sense?

My graphics wishlist:
1. Mirrors - enable sky, show car parts and 512x256 is not enough for todays standards ; )
2. Adaptive antialiasing - doesn't make any difference in FPS here, and yet it look much better
3. Shadows - from objects, higher res from cars...


Am I being too annoying?
Perhaps you're thinking of ILP vs. TLP?

http://en.wikipedia.org/wiki/Instruction-level_parallelism
http://en.wikipedia.org/wiki/Task_parallelism (aka thread-level parallelism, or multithreading)

The former is a much older technique and involves maximizing the utilization of all execution units within a single core to execute a chunk of code as quickly as possible.

The latter involves efficiently maximizing the utilization of multiple cores to run multiple, relatively unrelated chunks of code simultaneously.

Both are intended to improve performance, it's just that there aren't any compilers (yet?) that will write TLP code for you, so there is some extra effort required on the part of the programmer.
Hi Scawen, thank you for your reply!

Quote from Scawen :Hi, I'm not sure about doing this as I don't think it would be good to race using cross-eyed view.

I know cross-eyed view is a good way to get 3D from small images without any equipment, but I don't think it's a good idea for large images, or for extended periods of time. It might make your eyes go funny...

The same could be said about the parallel view side-by-side option. If half of your screen width is bigger than the distance between your pupils (which is almost certainly the case with say a 17" screen or bigger) you would actually need to point your eyes slightly outwards (Exotropia).
I for one am not able to do that - and believe me I tried hard!

I appreciate your concerns and indeed some people are having issues when trying to view cross-eye-stereo images. However I am perfectly fine with that, I've watched and made stereo images for years, even videos!

I just thought it would have been a nice idea to play around with. The basics (side-by-side display) are already there and I assumed all you would need to do is write a few lines of code to have that option of swapping displays. If it's too complicated for implementation I didn't want to bother you.

New Version 0.6F and Progress Report
(453 posts, started )
FGED GREDG RDFGDR GSFDG