Now there is talk about all kinds of graphical and computable improvements I have a completely different question which is on my mind for quite some time now. Well not only me but let me speak for myself. It's concerning netcode and then specifically pps.
Is it interesting to be able to support 8 pps instead of 6? Back in the days consumed bandwidth was costly but now this is not of any concern anymore. Would this 33% improvement be noticeable? Are there heavy drawbacks like considerable more processing power needed and/or is it hard to optimize this any further because the netcode should be adjusted to it more then out-standers realize?
Or is thinking that even more packets equals even more smoothing too easily thought and it has less of an effect because the prediction system already has enough info with this 6 pps?
Edited my previous post to avoid spreading false information. I found out that multiple CPUs were never (even on old computers) able to speed up single threads. Just like now, all they can do is save the original core (or CPU) some of its work (on separate threads). https://www.lfsforum.net/showt ... php?p=1861101#post1861101
Why do you need to know what Eric thinks about multithreading? I don't see it as some controversial thing which would polarize opinions...
It's pretty obvious what Eric would think. He would be happy any time I can give the graphics or physics systems more power. He would approve if I spent some time on it, but obviously not when some other things are more important, like supporting him with this Westhill update, as I am doing at the moment (reason for the delay on the anaglyph 3D).
while you are working on it, what do you think about some screens or videos to tease us before the big test ?
The layout of National track would be nice too (as I suppose it is not going to change now)
I don't mind if the whole development to the announced targets would take three or more years.
But one thing what I have thought often is about those LFS performance in nowadays PC's
It would be good to update it slightly. Today, computers are somewhat way more powerful than 2005 era. If development of tyre physics would take longer than three years, it might speed up little the development for not needing to make it work for every single PC of today's performance targets in development.
Of course, if development have gone on "critical" waypoint ( over 50% ), it would be a loss of the time.
EDIT: Of course, I think they have thought this too, so this post of my thought is something "not-so-useful"
But I am not the right person to talk, though. I trust developers know what they do
Then why I did start to talk?
Wanted to share a thought. If something bad there for you, a long tear will fall from my eyes. It shows to you only one fact: IDC ( The law of this community in these days, sigh...)
So you think the development takes so long because Scawen is targeting low CPUs?
Or what? If you think that for real, you have simply no idea what's going on. But thanks for funny post. (in real world the optimization of some code is usually the very last phase of development.. when you have something what works as you wish, only it is a bit slow on high end CPU .. then you spend some week(s) optimizing it, and there you go, done. I think Scawen is not at that phase at all, still developing the tyre simulation itself without bothering about performance on particular CPU)
Tested the new patch with my Samsung 3D TV. Everything worked fine so far
@Scawen: Tiny offtopic feature request (or bug fix) I would like to see with the next patch if possible:
In a nutshell, I would like LFS to use the lowres skin in a replay in case the highres skin is not present and not available for download anymore.
Explanation: I love to re-watch older replays. Some of the replays are from a time I didn't pay for highres skin download. Therefore the lowres skin is stored on HDD.
So, when now having the highres skins activated and starting such a replay, LFS sometimes does not find the highres car/helmet skins used in that replay. So LFS looks online to download those files, but most of them may be not available anymore. The current result is white cars.
The thing is, in this case LFS does not look in the low res skin folder for the skin file. Can you change that, please?
When I deactivate the highres skin option (Multiplayer -> Car skins download: 512) and start the same replay, those cars have the corresponding skin loaded.
There are tons of libraries that facilitate multi-threading and they aren't even difficult to use. However my stance is that one should only approach multi-threading when there are clear performance goals. E.g. if you can actually figure out the CPU loads on the target system and break that CPU load down to specific bits of the program so you know precisely where your bottlenecks are on a function-per-function level. When you can then quantify the benefit from multi-threading your code you can start thinking about what sort of effort you are willing to commit to the issue. (Then double that required effort because something you didn't expect will break terribly midway through the rewrite.)
I guess what I'm trying to say is "thread carefully" (pun intended ).
It might be also considered as problem in current tyre physics, because currently LFS has only one point on tyre where contact to road is detected. This can easily be seen if you tilt car to front/back a bit (UFR), part of tyre fall into the road. But anyway making curbs physicaly safer wouldn't be a bad thing, and my wild guess is wont take too much time.
In fact maybe some (very little) improvements can happen on multicore CPUs. Once I caught LFS using 65-70% CPU on a dual core CPU (for less than as second), the reason for that isn't because your code is multithreaded (not sure if you create any threads at all), but all kind of modules create their threads. If you check in Task Manager thread count for LFS, it is usually about 7-8. Creating Direct3D9 device makes like three additional threads...
For example my latest Texture converter even though internally it runs only one thread, looking at Task Manager says it is running six threads.
Not sure if this is a bug or it's because the new way 3D models are now drawn on screen.
Here's a comparison of 0.6E and 0.6F garage screens. You can see that the background that's visible through the windows seems to be black in 0.6F compared to 0.6E, where it's the garage background, as it should be.