valiugera : Shadows glich can't be considered as bugs, that's just the way vertex shadows works.
Hopefully, Scawen will work on soft shadow mapping to make LFS looks really nice
Not really.
Depends how often you delete/create new objects, you may either use some clever allocation to reuse the same 0..max indices for all objects (LFS actually has max_objects capped, so it can allocate single vector to hold them all), or ... switch off your common sense ... just move around the tail of vector every frame, omitting deleted objects. If you delete them all at one go, it's just O(N), and with the object max around 1k, it's faster to move around those 1k bytes, than handling a dereferenced linked list with O(1) insert/delete!
Because the 1k mem move is within one, maybe two, cache pages, the linked list with dynamic allocation will inevitably span over 4+ pages over time, and at that point you can do probably whole frustum culling + object delete + vector update in the same amount of time as the cache-miss penalties took.
As long as you stay withing cache page boundary, you can do hundreds of operations for free. Once your memory access pattern is not predictable for CPU, and requires many pages, you are at least hundreds time slower, or even thousands, if you miss even the top level cache, and you actually have to really fetch the data from RAM.
For CPU it's similar thing, as when human is watching loading data from HDD... Takes like ages...
I get a "Can not create swap file" error everytime I try to switch it to Oculus mode in the 3D setting of LFS. I reinstalled from scratch and have the same issue. Any ideas?
Well, I guess your explanation were a bit far for my current knowledge, but after reading this post several times, I think I finally got it, so thanks for learing me this kind of stuff !
But now, I have another question (yep, again, never stop learning) : If the max object number is fixed, isn't that better to use an array instead of a dynamic vector ?
@Scawen : I think Sleep of VSync is also needed for exit credits screen, CPU is currently at max on core 0 on credits screen (too much power needed for credits ).
Fixed the quote name! I made a mistake when editing the quote, because your quote had a quote in it!
Vec actually is 3 ints. In LFS the positions of objects are int (fixed point) so that they have the same granularity regardless of their distance from the origin.
I suspect a small bug has been introduced with the "Sky texture is now drawn in mirrors" improvement. The wooden barriers reflect the sky textures. I couldn't reproduce it with 0.6H
One more strange bug found. When I connect to host (with no cars on track) sky isn't shown initially. To reproduce this I need non-empty host, so that its not in the lobby screen.
I've fixed that in my version. It's objects with an alpha overlay not drawing the alpha overlay if there is a shadow cast near them.
Thanks, good find.
It is metres times 65536. The high 16 bits are the whole metres and the low 16 bits are the sub-metres. So the smallest possible increment in position is 1/65536 m (around 1/66 of a mm). This notation can represent values from -32768 to 32768 m.
Updated Italian, Romanian, Chinese and Turkish translations
I'm interested how this done. There is any chance to edit my nation language translation also ? And what i need to do for this ? Just open topic in other section and make a request of language ? And some of future test patch will contain new shadow system or any improvement of it ?
sti228 : Do you use the Georgian alphabet? If so, I don't think we can support Georgian at the moment. I think that would have to wait until some time in the future if we changed to the Unicode system or something like that.
sti228 : Do you use the Georgian alphabet? If so, I don't think we can support Georgian at the moment. I think that would have to wait until some time in the future if we changed to the Unicode system or something like that.
It is metres times 65536. The high 16 bits are the whole metres and the low 16 bits are the sub-metres. So the smallest possible increment in position is 1/65536 m (around 1/66 of a mm). This notation can represent values from -32768 to 32768 m.
Okay, this range gives you way much than the necessary to work with. But what is the real use, what do you mean by "the same granularity regardless of their distance from the origin" exactly, I'm not sure to get the point about this.
Take float for example. It lose precision as numbers get larger. Low numbers can provide good fidelity for sure (1.234567 m), but if number is large enough you'll get barely any resolution (123456.7 m) ~ 0.1 m
Fixed point - same number of digits, decimal point in the same place for all possible values.
Floating point - same number of digits, decimal point moves up and down.
In floating point, in effect some of the bits specify the location of the 'decimal point' and the other bits are the actual digits.
Anyway, fixed point (which is just an integer to the compiler) gives you the same resolution (granularity) over their entire range.
So, in LFS's 16.16 fixed point system, there are 65536 possible locations between 0m and 1m.
There are also 65536 possible locations between 10000m and 10001m.
This is not the case at all if you use floating point.
I understand what you mean now (and BTW, why float are so called float). Thanks for these very interesting informations.
I'll try to use it on my code as well now
It is metres times 65536. The high 16 bits are the whole metres and the low 16 bits are the sub-metres. So the smallest possible increment in position is 1/65536 m (around 1/66 of a mm). This notation can represent values from -32768 to 32768 m.
You can literally fit an entire city in that space. At what point does the engine say "no more, please!" and crash? I've LOVE to fit my entire city from Google Maps export into that space. It'd be fantastic for driver training with an Oculus Rift. Have people "respond" to calls within the game, have to use the real street directions. I'd really love to work on this ... I just need a little more information from you Scawen on the circuit format. .