Costa, I would really like to ban you from the master server. But in that case you would be forced to stay on the cracked version. That's not what we want. It would be good if you could put your efforts into making sure people leave the cracked version and get onto the proper version, so we can continue to develop Live for Speed.
Or maybe you don't want it to be developed any more, and you just want us to go and get another job?
If I see another report of you advertising on our genuine servers, I'll remove your access to LFS services.
The main problem is latency rather than bandwidth. In other words, the problem is the time delay between the server and the guest computers, not the frequency of the position packets.
Of course, we can't solve this latency problem by increasing bandwidth. In some cases the latency can be made worse by increasing bandwidth.
Each time a packet arrives on your computer, LFS runs that car through the physics system from the time it was sent, to the time it arrived, to try to predict where the car is now. It is always a bit wrong, of course, or sometimes a lot, depending on how long the delay was and how many driver input changes have been taking place.
Increasing the number of packets per second increases your CPU load (which can result in lower frame rates and worse latency - imagine this at T1 of a race) but will not get the cars into better positions than they already are, because that error is due to latency rather than bandwidth.
I think when you and other drivers are connected with good connections to a server with low latency, the other cars are not jumping around all over the place. Is that true? The problems begin when you or someone else has a laggy, high latency connection to the server. That problem wouldn't be helped by increased packets per second. In that case the lagging remote car would just flick more frequently into more of the wrong positions.
An interesting point on that is that although a correct calculation was used (in the current public version) the output effect is not fully realistic because the rendering is not done in a linear colour space. As the new graphics uses gamma correct rendering, the rendering takes place in a linear colour space, and is gamma corrected at the final output. Reflections come out brighter in the new correct version.
It seems to me he wants to keep telling people they are stupid for hanging around here, while he continues to hang around himself. He is telling people to accept reality, while using a fake account to post.
Why don't you use your real account too? Do you have something to hide?
It's always a danger if I actually tell people what I have been working on. So frequently it is some internal improvements, highly technical things that the average person has no concept of, or belief that's what coding could be about. We are just dealing with drawing pixels on a screen and vibrating your speakers, all with numbers. There is no car, no track, just triangles and code. People often cannot understand how vast the system is or how much time it takes to make improvements.
Anyway, I know that some people are interested in such seemingly small improvements, but was well aware of the 'danger' of people being unable to understand why I would work on them. Quite a few people now are using 4K screens and there were obvious flaws in the text rendering when drawing at larger screen sizes. So to someone like me, when I saw it that way, it comes across as a 'bug' or something that definitely needs improvement. Not a bad thing in any way to spend a week or two on those improvements, along with a massive graphical overhaul that has been taking place for years.
Technical explanation: For some characters, the Windows function GetCharWidth32W returns a width that is different from the width of the text drawn by DrawTextW, which is what I call to draw a single unicode character for a cache texture. I don't know why there is a width discrepancy but I've changed it to get the width by calling DrawTextW with the DT_CALCRECT option instead of GetCharWidth32W. It makes some sense because I'm now getting the width from the same function that is used to draw the text. This seems to work fine. Wide characters are still truncated on the right because these characters are copied into fixed size slots for efficiency as unicode characters need to appear and disappear on the cache textures and the slots are re-used. This is made a lot easier by all characters using the same size slot.
I am considering 4K displays now and the updated fonts do look better in 4K than they did before. They are generated using slightly higher resolution and more accurately. I don't have my own 4K display but I can use a special 4K screenshot mode so I can check how it looks by zooming in using a separate program.
I can reproduce this in Windows 7, which will be helpful for debugging.
The problem varies between fonts. MS PGothic doesn't seem to show the problem much but SimSun-ExtB does. That seemed the same here in a quick test in Windows 7 and Windows 10.
I would expect it to cut off characters that are too wide but don't know why it doesn't deal with narrow characters properly, so I'll have a look in the debugger.
They do use a common text drawing function but I changed the way that function was called. Now there is a standard text aspect ratio (which can be overwritten in some rare cases) instead of each caller deciding that for itself. So all the function calls needed to be adjusted and in some cases it was messed up where non-standard widths were used and had to be done a different way now.
It was already used in the Aston screenshots. The main change compared with the old system is that it can now deal with transparent objects properly. There will be a slight darkening near fences which the old system ignores. Of course in reality a fence does reduce the influence of sky lighting a bit. On the other hand the old system drew trees as the entire polygons without transparency, so in that case the sky was too occluded near trees. The hardware-based render takes account of transparency and includes all relevant objects so the brightness should be correct now.
Maybe you could remind me of this in a test patch stage, as I'd rather avoid looking at InSim for now.
Numbers have not been included in any of the kerning classes. And it was some years ago the '1' character had some invisible points added to make it the same width as the other characters.
That seems to be using Unicode characters from one of the code pages. I can see circles like that in the Japanese code page under extra page 81. But it seems OK with most fonts.
Maybe the existence of the bug depends on which font you have selected. It may be an LFS bug in some way (with wide characters) but there may be a workaround by selecting the correct font with Japanese language selected.
We have decided not to do a graphics progress report this month.
On Eric's side, things are going well as you have seen in the progress reports. But it does take a while because of the level of detail. There are still two tracks to update after he finishes the one he is currently on. We plan to show you some more pictures in December.
On my side I was working on sharing the lighting between tracks, but recently got diverted onto improving the sharpness of the text for the interface which then led to sharper dashboards and number plates. I was aware that it wasn't really necessary for the release, but I got an idea for a slight improvement that would take "a couple of days" and ended up doing a few weeks' work because of the improvements it led to.
Some people might be interested to know how one thing leads to another and can cause apparent delays in development. Warning: Technical details in the following paragraph! Feel free to skip to the before and after screenshots!
In fact this started from an improvement in the editor. Recently I had removed the software-based render for ambient lighting so now the images for the ambient lighting are rendered on the graphics card. After that update, which was important to help improve the graphics, there were just a few software-based drawing functions remaining. They include the editor text and guide lines, which were drawn by locking the back buffer and setting pixels directly. I converted these functions to use the graphics card's version of line drawing and the texture-based text as used in game. This finally allowed anti-aliasing to be used in the track editor which is helpful for Eric. But it did require some improvements in the accuracy of the in-game text. I decided to go through the font characters, thinning them a little, which took a couple of days once I had been through all the Latin, Greek and Cyrillic characters. Then I realised some of the character drawing wasn't really under control and I went through making sure it all made sense and upgraded the resolution a bit. This included visiting all places in the code where text was drawn, including the dashboards, so I doubled their resolution while I was at it. Also I noticed the number plates were looking quite bad so their resolution has been doubled as well along with more accurate text positioning. One more thing I implemented was "kerning" which is when you move some characters closer together for visual reasons. For example a classic case is A followed by V. The gap looks too big unless the characters are moved together. I had added a small tail onto the small L and this was causing a particularly bad gap between the l and t in "multiplayer" so I finally succumbed to the temptation of implementing kerning which I had wanted to do for years.
Here are some comparison shots to demonstrate some of the improvements.
I've checked and if I select Autocross X or Skid Pad X then there is nothing at the Drag Strip start, only the red tarmac.
There is an uphill area at the end of the drag strip that starts to rise gently about 620 metres from the start. At the 750 metres point it has gone up by about 0.8 metres. At 800 metres it's up by about 1.5 m and finally at the end, around 960 metres from the start, the height is nearly 6 metres.
I'm planning to make a converter for old layouts, that simply adds two metres height when loading. Clearly that won't work everywhere but it should mean that old layouts can be repaired relatively easily.
Yeah I know what you mean, I see those roads too and wish I could drive on them.
There are similar things at Blackwood. I don't know what the future holds for the external roads. I know Eric enjoyed doing that massive update at Westhill but it takes so long to do the main racing areas, there isn't really time at this point.
The trouble is all the tracks must be updated for us to be able to release the new graphical system at all. To do all the external roads can add months per track.
I hope some tracks might get a sort of Westhill treatment one day but I'm guessing it might be more important to do some car models first and then it might be time to add a new track. I'm just making this up though and this sort of prediction is usually wrong!
Aston hasn't gained a Westhill style open config, so there aren't roads to explore around the track. The only new road to drive on is the connecting track section in the screenshots. This is mainly an extensive graphical update with track width and corner tightness adjustments.
In the August and September progress reports we talked about the new shadows and lighting system and showed pictures of the updates on the Blackwood and Rockingham tracks. All our tracks must be updated to use the new lighting system and some older tracks need more changes to bring them up to date. Aston is one of them and is the subject of this month's report. Eric has made various adjustments to the track and tightened some of the bends while keeping the original flow. We hope you enjoy the pictures!
When you visit youtube it will show you things you've recently watched as it thinks you might be interested in them. They make more money (from advertising) when you watch more videos, so they try to show you things that may interest you (so you watch more things). It doesn't matter which site linked you to youtube. If you click a youtube link on LFS forum, you are visiting the real youtube. It's not an 'LFS version' of youtube or something like that. So as usual it will show you videos related to things you've recently watched.
As three_jump says, this is just a step in the right direction. I don't think there is time to add night version support in the next release because too many complications e.g. headlights. But what I do plan to do for now is share lighting between tracks, so each track doesn't have to just have 3 weather configs, but they can all use any of them.
It's just an experimental water shine effect as there are sprinklers there at Rockingham but it isn't currently supported by physics.
I don't expect to add any post-processing effects at this release. I need to finish up on the lighting and shadows so I can get to sort out the tyre physics and get that to a releasable state if at all possible. I can't bear the thought of trying to merge the current changes you see in the development version, into the public version. I want to get past that point where there are two branches and I want LFS back on the right track again.
Thanks! I need to remember that every time someone asks the same question, for each of them it was the first time!
I do know what you mean that although the cars don't look any worse than before, and in fact look better now with the self-shadowing and improved lighting, they can start to stick out when everything around them is up to a more modern standard.
Anyway I am sure that Eric is very keen to update cars when the tracks are done. I believe he could update some of them and we could do another patch some time after the tracks release. It shouldn't be necessary to update all cars at once. Ideally the oldest ones would be done first. But I'm not saying that's what will happen, because it depends what comes up and what seems to be the best thing to do at the time.
It somehow seems a bit of an annoying question, because it is quite obvious that many of the cars need to be updated (have a look at the RB4 for the most extreme example) but we are on the tracks at the moment. There is only one Eric. He does one thing and then another. Not both at the same time. It is obvious that he would not have failed to notice that the cars and drivers could do with an update.
What I do keep saying, every time I get this question, is that the tracks MUST be updated before we can do a release of the new graphical system, because with the new system, the graphics and shadows are broken unless the tracks are updated. So if we released now, you would have a game full of bugs. But the cars are no worse than they were before. Therefore they do not stop us doing a release.
This means, the cars have a lower priority than the tracks. There is no reason to delay the release by several more months in order to update all the cars. It is a separate subject, though it is quite obvious that they need an update.