Test was done without AA and without anisotropic filtering. And I get the same fps increase (around 30%) in full screen mode (as soon as I open nvidia control panel before running LFS), with whatever settings I use (AA, AF, small grid, large grid, AI or multiplayer race, different cars, different tracks).
Maybe someone with a nvidia card could try the same (I use 8600GT)? Open nvidia settings panel, choose the tabbed pane where it displays a 3D nvidia logo rotating (called "adjust image settings with preview"), and run LFS without closing the panel. Do you see a fps increase?
Maybe I should put this in another thread...Not a bug, rather a feature
And maybe only on my computer.I do not know if you read what happens with the fps, it was in the other thread.
When I run LFS in windowed mode (window covering the entire screen) I get the same 30% fps increase every time. In solo, or multiplayer mode,with large or small grid. It works all the time.
When I run LFS full screen with nvidia control panel running (showing a directx nvidia logo turning) I get 30% fps increase.
Very unusual behavior.
When I run LFS in windowed mode (window covering the entire screen) I get the same 30% fps increase every time. In solo, or multiplayer mode,with large or small grid. It works all the time.
When I run LFS full screen with nvidia control panel running (showing a directx nvidia logo turning) I get 30% fps increase.
Very unusual behavior.
And AI too.
Yes it was done to measure pure-display performance. In pause I am sure the fps increase/drop I see comes from changes I do in graphic settings.
Now when not in pause with 19 AI about to start, there is a fps increase too (50 max - 14 min with different cameras) -> (60 max - 19 min) when nvidia control panel open in background.
It is still 20-35% fps increase. Seems that when DirectX device is re-created, something happens.
I was using a texture pack already with the previous card and total texture size was 60MB. Disabling full res textures almost does not change the framerate, but number of visible cars has a big influence.
To exclude BMW F02 poly counts and AI/netcode influence I started a solo game with 19 AI on fern bay and FZ50 and then I pause the game to have only pure display framerate. FPS varies between 110 and 25 depending how many cars are visible (I switch view from car to car while in pause)
Then, if I switch to windowed mode with the window covering the entire screen...FPS increases a lot!(145-41).
And if I play fullscreen, but keep the nvidia control panel opened with the nvidia green logo in directX turning in the background...I get increased framerate too! (145-41). 30% fps increase!
Note: I use 2560x1024 resolution
Forgot to say: thank you for the amazing amount of work.
Last edited by Juls, .
Same thing here. Two weeks ago I used 6600GT and got around 60-80 fps with a large grid (patch X10). Now I have 8600GT (other card died) and it is slower whatever settings I use (in game and in nvidia drivers).
With the AI trajectory displayed, LFS is more enjoyable than ever for beginners. You can learn the track and go fast without any big mistake, and turn it off when you feel ready.
Sure some people will hate it because it is unrealistic. But it makes the sim more fun and accessible "out of the box". Tried yesterday with my brother. We have only 1 hour, we want to race ASAP, he does not know the track and played only a few times...he turns the trajectory on, I reduce air intake, and 2 minutes later we have a close race. Great!
Sure some people will hate it because it is unrealistic. But it makes the sim more fun and accessible "out of the box". Tried yesterday with my brother. We have only 1 hour, we want to race ASAP, he does not know the track and played only a few times...he turns the trajectory on, I reduce air intake, and 2 minutes later we have a close race. Great!
This is a lie. We, devs, are sane and healthy when we have enough pills per hour: :tired:
And nolife means nojail too!
Last edited by Juls, .
There is another formula you can use for FOV...
Let's say you are happy with a given FOV on a small screen (we call it smallFOV).
If then you use a x times larger screen, what FOV should you use to see the same thing than before in the center?
largeFOV= 2*atan(tan(smallFOV/2)*x)
For example if you are comfortable with a 90 degrees FOV on one screen and then you put three such screens together, largeFOV=143 degrees. With this FOV, center screen will look the same than before with only one screen.
If you switch from a 4/3 screen to a 16/9, x=1.33
90 degrees FOV on a 4/3 screen corresponds to 106 degrees fov on a 16/9 screen...etc.
Let's say you are happy with a given FOV on a small screen (we call it smallFOV).
If then you use a x times larger screen, what FOV should you use to see the same thing than before in the center?
largeFOV= 2*atan(tan(smallFOV/2)*x)
For example if you are comfortable with a 90 degrees FOV on one screen and then you put three such screens together, largeFOV=143 degrees. With this FOV, center screen will look the same than before with only one screen.
If you switch from a 4/3 screen to a 16/9, x=1.33
90 degrees FOV on a 4/3 screen corresponds to 106 degrees fov on a 16/9 screen...etc.
Yes... it is just good to discuss. And finally, most of these forums are for that....we discuss together mostly about LFS, and the great team do what they want.
As a user, I would like to have LFS improved faster. As a software dev, the way they work, this project, how independant they are...is a professional dream!
As a user, I would like to have LFS improved faster. As a software dev, the way they work, this project, how independant they are...is a professional dream!
Did I say we were 5 to go 5 times faster?
There was a clue: " Full control, 5 times faster...from my experience it is still easily possible with up to 8 people."
In fact there is something else to consider. When project gets larger, one developper gets less and less productive, because it is too large to have everything in mind and every time you jump from one part of the code to another you have to re-enter the problem.
Too many devs, too much overhead...not enough devs, overhead too.
OMG looks like we do need other people.
This is even used as a base concept for project management frameworks like extreme programming and more generally Agile development. (And of course, in this company where the boss hired devs to be his "arms", we had to do pair programming).
If you have a very good friend with the same motivation for the project than you, this is the best productive situation. Two motivated people working very close, and on the same keyboard every time it deals with critical code or if one dev feels down. Doing pair-programming all the time is boring.
Many great projects just die because people simply miss a good teammate. (I am working alone now and this is very hard to keep the pace on long-term projects).
Last edited by Juls, .
This explains a lot better why they want to stay like that. As soon as you hire new developpers and want to keep full control, you code less and become more a project manager.
Many coders do not want to manage at all, they want to code and I understand...managing is not such a nice job, and being managed is less fun too.
This explaination is 10 times better than the team-larger-than-3-produce-bad-things which is obviously wrong (if team is not too big).
IMO this is a (quality of) life choice more than anything else.
This is surrealistic...am I really supposed to explain that a software engineer project manager is able to make a 6 people team work faster than a 3 people team while keeping control?
Do you really think project management fails when teams get larger than 3?
Two people working on very close tasks work faster and produce better code than one. This is well known and not only for software engineering.
C'mon all this is obvious!
Sorry, but it is wrong. I used to work 6 years in a software development company, and we were like additional arms for the boss.
He was controlling every single line of code and we were not supposed to take any slight decision without asking him, and he was coding himself.
In fact he was a coder with a large project, and wanted to go faster and have consistant progress.
To do that he built a small team, with no hierarchy...just him and few employees. The way it was working allowed him to go 5 times faster, without losing any control, and without any stop if for example he had to stop coding for any reason...
Full control, 5 times faster...from my experience it is still easily possible with up to 8 people.
edit: I resigned from this job...being a stupid arm was killing me
Last edited by Juls, .
Is it possible that the main reason you overheat clutch...is that you do not feel acceleration in sims? (forgive me I am a bit obsessed with motion simulation)
I mean...without feeling acceleration it is difficult to know if the clutch is sliding or not, if we released the pedal too fast or not, where is the "biting" point of the clutch.
I did not try the patch, but is seems to me that handling properly a clutch in simulation is something quite difficult, as we clearly lack the way to estimate if we do it properly or not before it gets warm.
I mean...without feeling acceleration it is difficult to know if the clutch is sliding or not, if we released the pedal too fast or not, where is the "biting" point of the clutch.
I did not try the patch, but is seems to me that handling properly a clutch in simulation is something quite difficult, as we clearly lack the way to estimate if we do it properly or not before it gets warm.
If it was me (one can dream), I would use a library to manage zip files.
Then I would put data in the game as password-protected zip file without the header or something like that. It is not the best protection of course, but it is easy, fast, and it does everything necessary (CRC check to avoid changes, password protection, and compression in one step).
But this is pure speculation. I wanted to check that some time ago in order to add random tiny bumps in tracks...but I did not have enough time to search.
Then I would put data in the game as password-protected zip file without the header or something like that. It is not the best protection of course, but it is easy, fast, and it does everything necessary (CRC check to avoid changes, password protection, and compression in one step).
But this is pure speculation. I wanted to check that some time ago in order to add random tiny bumps in tracks...but I did not have enough time to search.
What they do is really nice. And they are able to attract many sponsors, and drivers. I suppose the simulator with attached helmet is too dangerous to be used by a person alone.
Their idea to make a virtual racing championship is really good. If there was a possibility to add custom tracks to LFS, I suppose they would use it instead of rFactor.
Edit: OMG I suppose I said something wrong
Their idea to make a virtual racing championship is really good. If there was a possibility to add custom tracks to LFS, I suppose they would use it instead of rFactor.
Edit: OMG I suppose I said something wrong
Last edited by Juls, .
I have been searching some time how to reduce this on various games.
In fact it comes from the difference between a real wheel and a force feedback wheel.
Real wheel is linked to the tyres through direction column. It means the wheel is always exactly where it has to be. If tyres turn a bit, wheel too, at the same time. No delay. Compared to the tyre forces, wheel and direction column have almost no inertia. Tyres lead the dance.
Force feedback wheel is not physically linked to anything, so it has inertia and continue moving alone unlike a real wheel. Wheel speed is different from in-game wheel speed. Force feedback wheel leads the dance. (in case of oscillations, in-game wheel speed is very close from zero when it reaches straight position, but at the same time, force feedback wheel still has some speed because of inertia, and will continue turning. The lag in USB control loop makes it worse.).
There are two ways to improve this:
- Improve the way the force feedback wheel simulates a real wheel. Simulate friction and damper in the wheel force feedback until wheel and in-game wheel have the same speed (in fact reduce wheel inertia. When you keep your hands on the wheel you introduce friction and damper and solve the oscillation problem). It works very well with ISI games...strong damper kills inertia when wheel is moving alone, and negative friction coefficient ensures that when you act on the wheel, damper disappears.
This could be done with a utility software comparing these speeds.
- Improve the way the games manage force feedback wheels....currently it is position-driven. Calculated forces depend frome wheel position and are applied to the wheel...it should be speed driven too.
Wheel should push more and more when it's speed is different from in-game wheel speed....more difficult.
In fact it comes from the difference between a real wheel and a force feedback wheel.
Real wheel is linked to the tyres through direction column. It means the wheel is always exactly where it has to be. If tyres turn a bit, wheel too, at the same time. No delay. Compared to the tyre forces, wheel and direction column have almost no inertia. Tyres lead the dance.
Force feedback wheel is not physically linked to anything, so it has inertia and continue moving alone unlike a real wheel. Wheel speed is different from in-game wheel speed. Force feedback wheel leads the dance. (in case of oscillations, in-game wheel speed is very close from zero when it reaches straight position, but at the same time, force feedback wheel still has some speed because of inertia, and will continue turning. The lag in USB control loop makes it worse.).
There are two ways to improve this:
- Improve the way the force feedback wheel simulates a real wheel. Simulate friction and damper in the wheel force feedback until wheel and in-game wheel have the same speed (in fact reduce wheel inertia. When you keep your hands on the wheel you introduce friction and damper and solve the oscillation problem). It works very well with ISI games...strong damper kills inertia when wheel is moving alone, and negative friction coefficient ensures that when you act on the wheel, damper disappears.
This could be done with a utility software comparing these speeds.
- Improve the way the games manage force feedback wheels....currently it is position-driven. Calculated forces depend frome wheel position and are applied to the wheel...it should be speed driven too.
Wheel should push more and more when it's speed is different from in-game wheel speed....more difficult.
Last edited by Juls, .
Sometimes I am too. Every time I order a part, it takes between two and 4 weeks to get it.
I don't think about anything revolutionary.
If you compare a frex-like simulator with a full simulator (moving then entire rig), what have they done?
They tried to simplify, while keeping the essential movements that make you feel the acceleration cues.
It brings several advantages...smaller actuators are needed, lag is reduced, size and price too, and it still feels very good.
I hope it is possible to further simplify. No simplification come without losses of course. But it is like mp3 or frex. If you can not feel the losses too much, you have won.
Last edited by Juls, .
Outsim acceleration
Hello. I did not find information about this.
Outsim gives acceleration vector and rotation speed.
Does this concern the center of gravity G of the vehicle?
If yes, is it possible to know the vector from G to the driver upper body in order to transform this data given by outsim into acceleration really felt by driver?
It may be quite different...if the driver is further from G like on cars with a lot of rear mass, rotation speed adds some acceleration at the driver level.
Edit:
Noone knows about it? I suppose I was not clear.
I just want to know if acceleration data given by LFS is acceleration of car center of gravity or acceleration of driver's head or....
Outsim gives acceleration vector and rotation speed.
Does this concern the center of gravity G of the vehicle?
If yes, is it possible to know the vector from G to the driver upper body in order to transform this data given by outsim into acceleration really felt by driver?
It may be quite different...if the driver is further from G like on cars with a lot of rear mass, rotation speed adds some acceleration at the driver level.
Edit:
Noone knows about it? I suppose I was not clear.
I just want to know if acceleration data given by LFS is acceleration of car center of gravity or acceleration of driver's head or....
Last edited by Juls, .
Yes of course. When I write about acceleration cues, I mean you can feel acceleration in all possible directions.
Do not laugh....this precise idea was patented in 1979.
http://www.google.com/patents? ... dq=acceleration+cues+coil
Assignee: The United States of America as represented by the Secretary of the Navy
Interesting discovery....a guy dared to patent basic motion simulator using a rotating base and cylinder actuators...in 2000:
http://www.google.com/patents?vid=USPAT6039653
Last edited by Juls, .
You are right to ask wether acceleration simulation is useful or not. I remember a few years ago, most of my friends told me exactly the same thing when I bought a wheel: this is a geek gadget.
After trying it they changed their mind. I suppose this is the same with acceleration simulation.
If we consider the problem from a simplified physical point of view.
The sum of all forces on an object give the instant acceleration.
The "sum" of instant acceleration over time gives the object instant speed.
Acceleration always precede movement.
The display and sounds of a racing game are always late compared to acceleration, because they are the result of acceleration on a heavy object, integrated over time.
In racing simulator without acceleration simulation, there is a delay between what we do and the perception of our environment. What we do now changes forces acting on the car elements, that is to say acceleration. What we see and hear are movements of the car, the result of past acceleration, the result of our past movements.
IRL, we have something more to help us: acceleration cues. We can feel acceleration and acceleration changes, which are the instant results of our actions on wheel and pedals. This gives us an instant feedback concerning our actions. We know from acceleration and our past experience whether we are acting in an appropriate way or not.
For example, we can immediately feel how strong we are pushing or turning and we can correct immediately, while without acceleration cues we have to wait until the effects of our bad behavior become noticeable to start correcting.
I think this is one of the main reasons why simulated driving seems far less intuitive than real driving for some people (this and field of view<>sense of speed).
Acceleration helps us in another way...it is absolute. I mean when you turn at a certain speed, you will feel the same acceleration in a mustang or in a mini, while the wheel force feedback may change a lot depending on your car and setup. At a given speed, you have to give the mini and the mustang the same lateral acceleration to follow the curve. And you can immediately feel if you manage to do it or not.
Last edited by Juls, .
Looks like this thread is a bit out of control, but a lot more funny.
Talking about patents, it seems that most ideas (tactile feedback, actuators, inflatable vests, headset with pulley or other things) have been patented before the early 90's and are now in public domain.
Have you seen how much costs a patent in Europe? When I think about the European Patent Office, I start smashing things.
Talking about patents, it seems that most ideas (tactile feedback, actuators, inflatable vests, headset with pulley or other things) have been patented before the early 90's and are now in public domain.
Have you seen how much costs a patent in Europe? When I think about the European Patent Office, I start smashing things.
Such a vest already exists. TN Games is launching such a product in November this year.
http://www.tngames.com
8 tactile actuators are placed in the vest...4 front, 4 back. According to their API, these actuators can be either on or off, there is no progressive pressure.
I suppose they suggest forces using vibrations of these actuators with changing frequency.
http://www.tngames.com
8 tactile actuators are placed in the vest...4 front, 4 back. According to their API, these actuators can be either on or off, there is no progressive pressure.
I suppose they suggest forces using vibrations of these actuators with changing frequency.
FGED GREDG RDFGDR GSFDG