I ported the sound test program to SDL library. With SDL I get a stable sound at 0.02 latency, on Vista, using a built-in Intel sound card. It is even almost stable at 0.01s, with rare audible cracks only when the system is heavily loaded.

Unfortunately using SDL does not really solve the problem, as SDL does not have an API to report playback position. It uses a callback mechanism. When it needs another chunk of audio data, it calls a user function. The easiest way is to generate sound in the callback based on whatever is happening at the moment on the screen - but then you loose temporal resolution. There are ways to improve the resolution, such as writing information about sound events to a log, with a time stamp of each event, then playing the log in callback, streching or shrinking gaps between events as required. However, it may add unneeded complexity.

SDL uses DirectSound API on Windows. It seems to use IDirectSoundBuffer::GetCurrentPosition to find out what is being played. I think this is a viable replacement for waveOutGetPosition. It does not seem to be affected by the Vista bug, and I guess it can be easily adopted without big changes to the program logic.

As a side note - both waveOut and DirectSound position reporting APIs are not very accurate. Undetermined amount of time passes between the driver getting position information from the hardware, and the information finally reaching the application. Time spent in context switches, interrupts, other tasks. ALSA solved this problem many years ago by providing a time stamp at which the position was sampled, thus allowing the application to determine the current position by extrapolation, with high accuracy. The same method is used in Vista's WASAPI.

If you are interested in the SDL based sound test, it is available from my SVN repository. The repository can also be browsed using a web interface.

Quote from arska90z :

Q1. Are you using wheel or mouse?
Q2. Are you using internal or external cam?

A1. mouse
A2. external

Use XFG on car park if you want to train, setup is here: http://www.lfsforum.net/showthread.php?p=127924#post127924
Ramps are not needed with this set.

No idea how many meters was that

Quote from AndroidXP :

(I'm not sure, but I think LFSW is mentioned within LFS, too?)

As can be seen on your screenshot, LSFW link doesn't look like a part of the menu. It doesn't even look like something clickable! People treat it like something decorative and doesn't even hover their mouse pointer over it, unless by accident. Which leads to dialogues like this:

andy: I'll send you message on LFSW
john: LFSW??
andy: yes, LFS World
john: <censored> is that???
andy: there's a link to LFSW on liveforspeed.net, check it out
john: where???
andy: left side
andy: below menu
john: there's nothing there
andy: it says Live For Speed WORLD, can't you see it?
john: the logo???
andy: YES, the logo, click on THE LOGO!
john: WHOA!!!!

* The names and dialog lines has been altered, any resemblance to the name, character or history of any person, living or dead, is purely coincidental and unintentional.

Quote from crumbut :

Date of cedega-files: 20040902

Very old. Try current CVS.

Quote from crumbut :

I cant give you a screenshot cause the Viewer will not run in Linux.

Works fine for me with CVS version of Cedega, which I installed using the excellent WineCVS script.

Quote from micha1980de :

acceptable...
at least we'd all have the choice, or to experiment.

From the user's point of view, the choice would be great. However, I would hate to be the one who has to support all the weird codecs and debug arising problems.

The problem is, there are lots of flaky, bugged, crashing codecs out there, and some people even have their whole DirectShow infrastructure seriously broken. When this stuff is running in the context of your process it may not only crash your program, but induce strange, hard to reproduce, hard to debug problems. It may corrupt your heap memory, leak your process resources, leave running threads behind, and you as a programmer don't have any control over it.

As a programmer, I would probably choice ffmpeg libraries with a few carefully selected codecs and few encoding settings. I would bundle all the dlls with the app and no user installed crap could break it. To satisfy advanced users there could be an option to just write raw audio and video data to a socket and let an external app handle it, similar to In/OutSim/OutGauge.

Quote from avellis :

BUT, perhaps a mirror has been compromised and an LFS download might as well contain viruses or trojans.

An MD5 on the main server would be perfect to check for the validity of files downloaded from various mirrors.

Not perfect, but a step in the right direction

Care should be taken to correctly handle mirroring. There were already cases when upstream sources were compromised, then mirrors just picked up the modified files together with modified checksums and raised no alarm. The irssi irc client compromise was not caught by mirrors, but by users and linux distribution package maintainers, because their package building scripts complained about checksum mismatch.

What I would really like to see is major Windows download sites to provide file checksums, because the more widespread usage, the higher chance someone will spot tampering.

And while we're at it, the open source world is moving away from MD5 because of its flaws. Better use SHA1 instead.

There is no need for md5 checksums just to find out if your downloaded zip file is corrupted, because zip files contain checksums inside them. A corrupted zip file will not unpack without an error. Zip checksums use Adler32 hash function which is not cryptographically strong, but good enough for detecting download errors.

Sfv is even more worthless, as its CRC32 hash function is as weak as Zip checksums.

However, a cryptographically strong checksum could be useful to detect if the file has not been tampered with. The problem is, if the checksum is available from the same place as the downloaded file, how do you know it has not been modified too? Thus, the checksums should not only be provided on liveforspeed.net as suggested, but also independently from other download sites and thru other channels.
_________________________________________

LFS_S2_ALPHA_U.zip: 144411427 bytes
MD5: c79c115cd6998fb343286a37b22e5ba4
SHA1: f27ae892ee8b95b6d96dd14b804603a2d21ad693

Maybe I am mistaken, but it seems to me like some dirty anti-debugger protection isn't working on Vista. Why not get rid of it altogether? It is not an issue for the crackers to break it anyway. When the new version of LFS with BF1 was released, the crack was in wide circulation only a few days later.

Quote from BuddhaBing :

My understanding is that the FF is generated directly from the forces in the underlying physics model and does not use canned effects that are triggered once the car enters into a certain state.

Yes and no. DirectInput offers both direct setting of a force by an application, and predefined effects. Effects are useful for rapid changing forces like shakes, and forces dependent on user input like friction. The device driver or preferably the device itself will take care of the effect, thus relieve the application from having to send several carefully timed force setting commands per frame in the first case, and decrease lag by eliminating round-trip of information between the application and the device in the second case.

Quote from wheel4hummer :

That bloom effect on the roof is AWESOME! It's cool how using a 2d plane, and just the right angle, it looks almost 3d.

Indeed. Glow is cool. People like glow.

One of my early experiments was to load a default skin template and apply a glow filter. 5 minutes of work. The funny thing is, people liked this skin more than many others more complex and laborious skins.

Last edited by StuntCarRacer, Sat, 10 Jun 2006 15:28.

Clean racing taken literally.
First version.

The zip file contains all the source files needed to recreate the skin: Inkscape SVG document, images, and QuasiChancery font. Public domain, except the font which is GPL licensed.

Quote from Vain :

That's a great idea and a nice looking skin!
Though jeans-texture looks a bit blurry to me. Can you beef the resolution of that special texture up a bit? The rest looks good!

Thanks. Indeed, the texture isn't too good, but I could not find a better one. 99% of what I found were normal scale photos, not close-up macro ones. The rest were either low resolution, or out of focus, or hard to tile, or otherwise not fitting the design.

Quote from MAGGOT :

I think it would have been beneficial to have made this on a 2048 res skin, using Bunta's skin kits from Master Skinnerz

I'll go look for it, thanks. I visited that site looking for textures, but I guess the skin kits have not caught my attention. It is my first try of making a "real" skin (others were only: load default template, apply random filters, test how it looks ).

One day I stumbled upon a nice jeans zipper picture on the web, and I had that stupid idea to make a crazy UF1 skin from it. You can find the result of some experiments attached.

I am not pleased by the result. It does not work well in-game. The main feature of this skin is on the roof, thus not visible most of the time. The jeans texture is not easily recognizable, especially in the low resolution online version. Thus I am not putting more work into this.

For everyone who wants to continue where I left, there is a layered source image from GIMP 2.2 available. It is packed with 7-zip (why 7-zip? - because my upload is limited, and 7-zip came out 1MB shorter than zip and 200kb shorter than rar at highest compression). Do whatever you like with it.

If you watched my replay of 2 wheels xrt driving, you may have noticed how extremely lucky I was. I needed probably around 100 tries to make that replay.

Today, after endless repeats, I need only a few tries to put this car on 2 wheels. Somehow my brain found a new, much more reliable technique to do it. I haven't invented the technique consciously, I'm not so smart (if I was, I would probably be saving the world right now, or at least doing something productive ).

Take a look at my new replay. As you can see, when my inner wheels go up a bit I quickly counter-steer, forcibly bouncing them off the ground. This move sends my inner wheels high enough in the air to start 2 wheel driving. No more relying on uncontrollable drifts and bounces to lift the wheels.

Forget it, most sets won't load after renaming, because "name too long". :doh:

http://www.videolan.org/vlc/

Download the zip version and unpack to your pendrive.

2 more:
MRT: set replay
FZR: set replay

Quote from Metalstar :

Hello all - I've been doing alot of moaning about driving standards at the moment, so i decided to take some time out and do something useful!

Thanks. I used the table to write a short Perl script to rename my sets:


It will add the name after the track symbol, so for example GT_as7r_erase1288.set becomes GT_as7r-north_erase1288.set

Quote from sweetreid :

Answer to: Is there a Linux or Mac port available, or will there be?:
No, there is and will be no port of LFS to Linux or Mac. Doing this would take a huge effort and a long time and because our development team only consists of 3 people, we simply do not have the manpower to do just that. The time we would spend creating a port can be much better spent improving the sim itself.

It doesn't mean that a port for other platform can't be done by some 3rd party company like Icculus/LGP, Aspyr, Transgaming and others, with minimal involvement of LFS dev team.

Quote from Woz :

LFS is a Direct X application, and I can't see MS porting DX to a Mac. For the devs to port from DX to OGL requires a huge amount of work.

There are both open and closed source DirectX and Win32 API implementations for other platforms.

2 wheel sets and short replays:

XFG: set replay
XRT: set replay
UF1: set replay
UFR: set replay
XFR: set replay

No ramps are needed to put a car on 2 wheels with these sets, with some caveats: with XRT it is extremely hard, and UF1 may be driven on the side on which the driver is sitting only. UF1 has only open differential, so it's impossible to accelerate.

Quote from avellis :

Now, I can think of two solutions:

1) Downgrade to an older wine version
2) Install wine to an identical machine with X-Windows enabled, and then copy over the registries files.

3) Run it on Xvnc

Quote from Becky Rose :

The problem for C++ coders (and I am assuming LFS is coded in C++) working on the PC is if they use a library which has no Mac equivellent then whatever library they used has to be totally replaced with something new on the Mac.

It seems LFS does not contain any 3rd party libraries except Microsoft ones. I may be wrong of course as I don't have the source code, but if we assume that is the case, then the only thing that needs to be provided for Mac is implementation of Win32/DirectX APIs.

One such implementation is provided by the Wine project. It is LGPL licenced, so it may be linked with closed-source product just like other LGPL libraries (SDL, OpenAL etc). LFS works quite well with Wine's DX implementation. There are still some issues with shaders due to differences in color format between DX and OpenGL shader model (BGRA versus RGBA), but having the source to both LFS and Wine's DirectX these issues may be quickly solved. In such case you don't need to fix Wine's shader to make it work for all cases, you just need to fix it for LFS, or tweak LFS shader code to make it work.

Another implementation is Transgaming's Cedega. Their DirectX implementation is under AFPL, so can't be used in LFS directly. Hovewer, if the demand for LFS on Mac is high enough, it may be profitable to contact Transgaming and do a port with them. LFS will gain marked share, and Transgaming will have one more title working perfectly on Cedega

To sum things up, Mac port of LFS may be easier than it seems. It all depends on how well LFS is written. It there are lots of endianess problems or big hairy asm blocks, it will be harder. But it is still far from rewriting the whole game, or ripping out the rendering engine and replacing with OpenGL one, as some people suggest is similar threads.

Attaching a replay of driving on 2 wheels... sideways. No screenie, as I don't have any fancy AA or shadows. Besides, the screenshot wouldn't look interesting at all

Greetings to all car park crashers. I wouldn't even think of driving like this without their help