Good job, looks very nice new project of S3

again off topic but regarding recent stuff that has discussed

http://www.techrepublic.com/ar ... -still-willingly-at-risk/

little extract regarding the amount of people still using xp

"General worldwide estimates still put Windows XP at nearly 30% of the overall desktop operating system market as of the end of March,"

Quote from 5tag :

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).

Side-by-side isn't actually displayed like that (except maybe on VR headsets where it's in-your-face), there is trickery within the monitor to present a single 3D image.

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

I wonder, what does Eric think about this multithreading stuff?

Quote from hackerx :

I wonder, what does Eric think about this multithreading stuff?

If he's anything like the artists I know he probably can't even spell it :P

Quote from hackerx :

I wonder, what does Eric think about this multithreading stuff?

Quote from Eric :

I don't answer to anyone. Get over it.

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).

Quote from Scawen :

... 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)

We've already had the massive tease! We're now already being teased by not knowing when it will be released. Let Scawen get on with doing what is needed :-)

Quote from PeterN :

We've already had the massive tease! We're now already being teased by not knowing when it will be released. Let Scawen get on with doing what is needed :-)

He said "Few weeks", 2 weeks are over now so i guess two more because then it will be a Period of month

/*irony off

"A few weeks" does not necessarily mean 2 weeks. It can take as long as a month, depending how quickly Eric and Scawen prepare it for public testing.

Haven't we been there with the "promise" to release something during a week? Come on, just be patient

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...)

Back to elsewhere --->

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.

Quote from Ped7g :

snip

Wow...Okay, yes you are right, I am sorry...

--->

Quote from Scawen :

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).

Now I can't help but wonder, what does Eric think about what Scawen thinks about what Eric does think about multithreading stuff?

Why? There's this conspiracy theory that Eric does not exist. So far I see no proof that he is real, and your post there only adds to suspicion.

Quote from hackerx :

So far I see no proof that he is real,

Oh here we go again; https://www.lfsforum.net/showt ... php?p=1858066#post1858066

They specially flown in some actor for that video, I bet yah.

Quote from cargame.nl :

They specially flown in some actor for that video, I bet yah.

Yeah, even the Greeks could not find Eric: http://wiki.answers.com/Q/Who_is_Eric_in_greek_mythology

I'm curious now what the plan is with Rockingham?

Quote from Becky Rose :

...
I'm curious now what the plan is with Rockingham?

it was planned to be part of S3 content ...
=> so after WestHill update and after tire physics update (I do not mention 3D stuff, because less interested personnally, so less in touch)

Quote from Scawen :

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.

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 ).

Vain

How hard would be to give a little fix to some of the current tracks other than Westhilll?
I primarily think about Kyoto curbs.
https://www.lfsforum.net/showt ... php?p=1795547#post1795547
https://www.lfsforum.net/showthread.php?t=8500

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.

Quote from Scawen :

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

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.

tinted windows ?