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.
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.
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
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.
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..."
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.
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.
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.
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...
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.
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?
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
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.
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...
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.