Bose speakers have always been over-priced and/or gimmicky. This tradition started with the Bose 901's (over-priced and gimmicky) and has never stopped since.
I don't know much about PC speakers. I either use headphones or a stereo with normal speakers with my PC.
The best PC speakers would be true near range studio monitors, but these aren't cheap and you'd need at least a power amp (QSC power amps are cheap but good). "Near range" means they are relatively close to the listener. Studio monitors are also middle and far range, with the far range versions handling the most power and producing the strongest sounds.
I haven't shopped for speakers in ages, as they last a long time. Good stereo equipment was long ago replaced with lower quality home theater equipment, and the good stereo equipment prices have escalated as their popularity has decreased.
The main thing is to find a pair of speakers that you like. The things to listen for is the quality of the sound and if that quality or the frequency response is affected by volume level. Sometimes the sound becomes harsh due to actual distortion, or because the speakers are more sensitive to mid to high frequencies at higher volume settings. Other speakers become boomy, sounding like cheap car speakers, "muddying" up the base so it's no longer "crisp" at higher volume settings (this is an issue with many home theater type speakers).
In the USA, logo's are covered under trademark law, since copyright laws don't cover symbols that closely resemble actual trademarked logos, but trademark laws do (for example to prevent "knock-off" items such as purse that looks like a Gucci purse). Trademarks aren't automatic though, they have to be filed.
Single words and short phrases can't be copyrighted. Short phrases are difficult to trademark. Then there are the fair use laws in the USA:
The closest thing to a standard is the youtube standard. Generally as long as credit or a link is given for the source to a video, there's no issue. If there is a complaint about video content, youtube will ask the poster to counter the claim or to remove the video.
Youtube does some automatic screening, based on keywords in the titles or descriptions of posted videos, but not the actual video content. However the auto-screening has been an issue, for example, Viacom was tagging "tomb raider underworld trailer", even though they were only one of several companies making these trailers. It became a moot point when the game itself included a high quality version of the main trailer as an intro video (since Eidos then owned the rights and didn't have any issues with the intro being posted).
It's isn't infringment until someone complains or includes some type of clause where it's shown, such as the clauses about not re-broadcasting sports events shown on TV, or the do not copy clauses on games or videos. At the other end, GNU licensing uses copyright to prevent any infringement claims. So the legality depends on the claims regarding infringment or potential infringment.
Bottom line, I doubt any company is going to complain about a logo used in a niche market racing game.
Transmission modeling isn't too big a deal for me, since I'm not a true enthusiast, and I'll just program some macros to do whatever it takes to implement clean shifts at the touch of a button (with the CH USB controllers I use, that button can be translated into lift throttle, depress clutch, shift gear, modulate throttle, release clutch, return throttle control back to controller position, with appropriate delays between each action), the equivalent of an aftermarket no lift sequential shifter setup such as an XTRAC.
I've only tried the free trial version that has the Solstice, Legends, SRF (Spec Racing Ford), and the Radical SR8. The Legends is the one exception in this group, it's happy to turn with lift throttle, but spins easily if power is applied. The SRF is the worst, apparently due to exagerrated physics of it's open differential. I don't know what the Soltice uses for a differential. I assume the Radical uses a LSD, but since iRacing doesn't include any differential options in the setup menu, there's no way to know.
Induced understeer can be used to counter lift throttle oversteer. In my short time with iRacing, it worked with the Soltice and Radical, didn't work with the SRF, and wasn't useful with the Legends. In the case of iRacing, if you start to lose the car to a spin, you can combine induced understeer with braking, to keep the car pointed forward and on track to avoid incidents which hurt your SR (if you care about this).
I made a video with the Radical at Silverstone, using lift throttle oversteer countered with induced understeer to scrub off speed while drifting during corner enty to apex stage.
At Lime Rock the bumps at the end of the last turn are an issue for the Radical using the basic or advanced setups. The turn can be taken at the limits, but then the car almost always spins just as it reaches the straight. I downloaded a setup from Dom at Team Redline, changing the gearing back to short (his was set to medium), to make this video. The car get's bounced around on that last turn, but it doesn't spin. I didn't bother looking into what Dom changed, as I don't plan on staying with iRacing.
OK, so it's not LFS, but the Radical in iRacing seems happy using a bit of induced understeer, at least with the default "advanced" setup. I'm not sure how long the tires would last when drifting through the turns as I do in this video, but it sure is fun. Slip angles aren't as high as they are in GPL, but the driving technique of using lift throttle oversteer to scrub off speed in turns feels similar.
Although my example is a bit extreme, a player can just press both shift and clutch at about the same time, and it doesn't matter which button is pressed first.
With auto clutch on, the shift time is whatever time the game uses for the auto-clutch duration. With auto-clutch off, the shift time is the time it takes to press and release the clutch button if you exploit the manual shift sequence. I'm not sure which is faster. This is an example of the auto-clutch off exploit shift sequence:
For a sequential shifter the sequence for each shift is:
press and hold shift button before you want to shift.
tap clutch button to cause shift to actually occur
release shift button
I've since read about that, so that would make it 0/100/0 differential in GPL LSD terminology. The effect on the SRF in iRacing seems to be exagerrated beyond reality. Also induced understeer didn't seem to help with the SRF. Induced understeer did work with the Radical though, and it always has with the cars in GPL, so at least one car in iRacing behaves like the old Papy cars.
I never claimed that induced understeer should be used exclusively. Opposite lock should be used depending on the circumstances. For some cars, both in real life and in racing games, induced understeer is useful. It works well on the Radical in iRacing, at least with the default basic or advanced setups provided by iRacing.
Depends on the cause of the lift off oversteer. If it's because the coast side ramp angles in a limited slip differential are set too "loose", then you're just trying to mask a differential issue with a suspension setup.
In the case of iRacing, the SRF (scca Spec Racing Ford), has a terrible differential setup, way too loose on lift off throttle and too tight under power. Some players have tried to mask this with suspension setups, but you end up with a car that's too tight under power. The other option is left foot braking while keeping the throttle engaged. The SRF needs about 1/4 to 1/2 throttle in turns depending on the gear and speed.
I got a chance to run a couple of test sessions with a friend's installation of iRacing, and steering induced understeer works well with the Radical, making easy to counter lift throttle induced oversteer to balance the car.
Another reason I liked the Radical is that induced understeer works with it, making it a bit easier to counter lift throttle oversteer during corner entry.
I got to check out iRacing at a friend's house and made the same discovery, it needs about 1/3rd to 1/2 throttle to be happy, depending on engine rpms.
It appears to be due to the differential, the coast side ramps are set too loose, and the power side ramps are set too tight. If this was GPL, it would be the equivalent of an 85/85/4 differential. The problem is that I could see no way to adjust the differential, and trying to compensate for this with suspension tweaks would end up making the car even tighter under power.
With it's screwball differential setup, the SRF's (scca Spec Racing Ford) only purpose would seem to be to teach left foot braking (while modulating the throttle with right foot) Otherwise it's a terrible setup, and worse yet, it's intended for the novice drivers. It would be the the car of choice for the "we're glad LFS is harder and more realistic now club ".
After testing all the cars you get with the free 1 month trial (promotional code is PR-RADICAL-ONE-MONTH), the Radical was the easiest of the group to drive. It's differential setup (not adjustable on any of the cars I tested) seemed reasonable, leaving the in game suspension setups to be enough to taylor the car for a particular driving style. However it would take months for a new player to be able to race with the Radical becase of the marketing scheme where class advancment is slow.
The Solstice was gutless with not much grip, not a fun car. The Legends was the opposite of the SRF, happy with lift throttle during corner entry, prone to oversteer under throttle.
So would that put LFS, in the "quite good 3 years ago" class, when patch T was released, fixing the previously bad physics? I haven't seen much progress in the physics since then, other than adding some forms of damage like the poor clutch overheating model.
It won't be long before games like rFactor 2 and possibly NFS Shift surpass LFS in terms of realism.
In the case of GPL, I still think it's an excellent sim. The cars are essentially LX6's with 400hp combined with more forgiving bias ply racing tires, with real tracks, or at least real historical tracks.
Sorrty, I left out a paragraph. Hewland sequential shift trannies can be shifted without the clutch, and depending on the electronics, shifted without clutch or without lifting. Another common brand of no-lift sequential shifter is made by XTRAC.
A racing form of DCT (dual clutch transmission) has dual clutches with even and odd gears running on different shafts, allowing for overlapped gear engagement during sequential shifts. DCT's are banned in Formula 1 racing, but the new "seamless shift" gearboxes are allowed, and there is still some overlap during a gear shift, combined with computerized control of clutch and fuel injection to smooth out the jerk on the drive train, while maintaining positive torque and power to the wheels.
So the holy grail of the seamless-shift gearbox is to replace the dog rings with something else – something that selects the next gear before the current one is disengaged:
Racing transmissions like the Hewland use dog ring type setups, which don't need synchros. During a shift on a racing transmission, there's a period in time where both gears are engaged at the same time, but it's not an issue, since thost transmissions aren't meant to last as long or be as smooth as a passenger car transmission:
Just because you can shift a racing transmission without using the clutch, that doesn't mean you have to. "Some people shift with the clutch, some people shift without," Hemmingson explains. "There is no best way; they just do whatever works best for them. People that drive right foot gas, left foot brake usually find that it works better for them not to use the clutch. Then there are other people that drive heel/toe and use the clutch, but there is no set rule because people are better at different things. :
Depending on the rear end differential, engine braking can be setup to modulate the locking factor between the rear tires, controlling the oversteer response to engine braking while slowing down for a turn. Using engine braking to induce oversteer will slow a car as well as keep it turning inwards, a method that works very well in games like Grand Prix Legends, allowing corner entry to be a bit faster, and used as an alternative to trail braking. The sensation is that you "drift" your way towards the apex, but the tires aren't completely sliding in the process.
mmtimerf.c - 1ms timer via callback function (like an interrupt routine)
mmtimert.c - 1ms timer via thread (timer sets event that the thread waits for)
I tested these using Visual C 4.0 (1995) and Visual Studio 2005.
I tested on an old 2.0ghz Pentium 4, D850GB motherboard (2001) system running Windows ME and they run just fine. This is a system that predates LFS by 1 to 2 years.
A multi-media timer. The wiki article was wrong. Multi-media timers predate HPET's and can run at 1ms => 1000hz and have been available since Windows 95:
The HPET spec requires a minimum 10mhz source clock. http://www.intel.com/hardwaredesign/hpetspec_1.pdf
From my quick web search, the HPET's can be run at 100 usec => 10000 hz. I don't know what the limit is, other than system overhead.
In the sample code linked to below, setting uDelay to 1ms would result in TimeProc being called once every 1 ms.
The RTC (Real Time Clock) is a different piece of hardware. The RTC is a Motorola 146818 or the equivalent, normally uses a 32.768khz "crystal", it's a low power CMOS device, and is not as accurate the 8253/8254 (or equivalent) and it's 1.193185mhz crystal. It's main purpose is to keep track of the time of day while the PC is turned off, running off the washer sized battery on the motherboard.
On newer systems, a high precision timer is available and referred to as the "multi-media timer" in Visual Studio. These should be nearly identical on all PC's.
Since LFS is meant to run on older PC's and perhaps Windows 95, it would use timer0 on the 8253/8254 or it's equivalent, indirectly, but this is an accurate timer.
Numerical intergration is used when differential equations that can't be solved directly. You start of with a known position and velocity and acceleration. The only thing you can directly calculate is the acceleration. So given this, you "integrate" the acceleration for .01 second, and predict a new velocity. Based on this predicted velocity, you use the average velocity during the .01 second to predict a new position. Then the cycle repeats itself. Different math methods improve the accuracy, but reducing the step size helps the most. Using a step of .001 second would be more accurate, but would require a 1000hz physics engine if needed to be run in real time.
This can get very complicated. In space, gravity is diminishing with distance, and time dialates a small amount due to relativity. The more accurate the math model is, the less fuel consumed to do course corrections during space travel.
Near the earths surface, aerodynamic drag is extremely complicated, especially in the case of super-sonic objects.
In the case of a car, stuff like the suspension and tread movements move too quickly to be properly modeled on current PC's. I've read that you'd need a physics engine running at 10,000 to 100,000hz to do an accurate job, and you'd need an extremely good mathematicl model to do this. From what I understand this isn't done for real cars, so the modeling stops and real testing starts with prototypes to discover any hidden problems.
If the modeling was accurate enough and used, then stuff like blow overs wouldn't happen (the driver was OK):
Virtually all PC's use some equivalent of the crystal that runs the virtual 8253, specified to run at 1.19318 mhz (1.193175mhz -> 1.193185mhz, a variation of less than .00042% is allowed. Some motherboards do violate the spec if run in an overclocked mode.
If the physics engine is run at 1/2 it's normal rate, then the time deltas used for numerical integration are doubled. This would decrease the accuracy and create a slight difference in peformance. Still it's better than not being able to run the game at all.
I've seen what appears to be similar behavior in other games when using fraps to record post race replays. On some games, if I wait until after a race is completed, and then use fraps to record the replay, the replay runs in slow motion. The usual fix is to run fraps for at least a short while at the start of the race, apparently when the game is adjusting it's internal engine rates, aftewards, I'm able to capture the replays via fraps. If the physics engine rate is being altered, then this is affecting the game play. Usually it's just the graphics engine that is being dynamically altered.
If anyone here is interested, the physics of a real or gaming car involves differential equations that are too complex to be solved by integration, so numerical integration is used to convert calculated accelerations into velocities, and then into positions. Runge-Kutta is a commonly used method:
I don't know how this could be done with Windows NT, 2000, XP, Vista, or later systems, as direct I/O and interrupt intercepting is locked out.
Visual Studio has good support for multi-thread debugging (only the current thread is affected by a breakpoint, the other threads continue to run). Visual Studio Pro (the one you buy) supports remote debugging between two computers, the debug screen is on the "host" computer, while the applciation and it's screen runs on the "target" computer. In addition to Visual Studio, Microsoft has a good set of additional debugging tools, probably beyond what is needed for debugging a game:
I'm don't understand what you're getting at here. Is "delta" a constant, or a value set by some hardware?
How often are you executing this code fragment: if (myTimer > 100)...? Is it part of some large processing loop where the code periodically checks some hardware timer for a timer event?
Instead of doing perodic checks for elapsed time in the main code, Windows allows the equivalent of an interrupt to call a function or set an event at some fixed frequency via timeSetEvent(). The fixed frequency code resides in the function that is being called, or in a higher priority thread that waits for the event to be set (signaled), running independently of the main line code. In either case, the current (lower priority) thread is interrupted and control is given to the fixed rate function via a call or thread via an event. That fixed rate function or thread can then communicate with the other threads via messages, or events as needed. Once the fixed rate function has completed (returned from the called function case, or waitfor...object from the event driven thread case, control returns back to the previously running thread, eliminating any need for that thread to "monitor" a timer.
As mentioned before, the fixed rate process could either call or set event flags for other fixed rate processes, such as the graphics thread, which was triggered once every 5 cycles in my previous example to reduce the frequency from 500hz down to 100hz.
Here is where the multi-threading approach helps. The physics engine runs at 500 hz and needs to complete in less than 2ms, leaving enough cpu bandwidth left over for the rest of the game to function. The graphics engine runs at 100hz, and may take more than 2ms per step, so it couldn't be called directly from the physic engine thread because it would cause the physics engine to overrun it's timer. As a separate thread running at 100hz, the graphics thread has up to 10ms to complete without causing any problems to the game, and no special coding is required to split up the graphics thread into sub 2ms steps, since while the graphics thread is running, the physics thread will interrupt the graphics thread as needed so that the physics thread operates at it's 500hz. Each thread operates independently and has seperate criteria for meeting peformance goals. Neither thread requires any knowledge of the state of the other thread and the threads operate independently.
A problem with our terminology here. I'm using the term "multi-threading" to mean any form of multi-tasking, which until relatively recently was implemented on single core cpu's. It just so happens that Windows will automatically use multi-cores on multi-threaded programs, but there has always been a significant advantage to writing multi-threaded code, even on a single core systems, depending on the application.
The example code I created in "mtcopy.c", uses two threads so that reading and writing of data can occur concurrently without having to use special forms of I/O calls that return immediately after starting the I/O and require the program poll for completion or to specify a callback routine to handle the completion step, similar to an interrupt routine. Instead each thread just issues a normal start the I/O and wait for completion, and the OS automatically switches between the threads while they wait for I/O completion or wait for messages or events (event, mutex, semaphore) from each other.
But generally they have timers that run independently of the CPU. PC's have always had an actual or emulated 8253 timer running at 1.19318 MHz, classically used to drive the DRAM refresh rate, and divided down by 65536 in the BIOS and in MSDOS to get a ~55 ms => 18.2hz "ticker" interrupt.
Windows default timer functions run at 15.625ms => 64 hz, and the "multi-media" timer runs at 1ms => 1000hz, regardless of the PC speed.
As mentioned before, Windows 95 supports multi-threaded applications, and many games have been multi-threaded since then (1995). Some of those older multi-threaded games are having issues with multiple cores, typically due to a issue with directx. Using a opengl driver, if possible, usually eliminates the problem, or setting the affinity via task manager to a single cpu may be required.
Synetic is a small developer with about 8 people, and their games (World Racing, Cobra Alarm) are multi-threaded.
I tend to use messaging. The overhead involved in copying the data is usually small compared to the overhead of thread context switching. I already mentioned the alternative of using two objects referenced by pointers, and simply swapping the pointers as an atomic (mutex may be required)operation to switch between the current and the in process version of the objects. Here the size of the shared (between threads) object and the time it takes to update the object determines which method is best.
I prefer the event driven approach. In the case of the fixed rate stuff, this is normally dealt with by having a timer based event that triggers at some fixed rate. If a thread, such as a physics engine, runs at 500hz, then a timer triggers an event every 2 ms. During development, there's usually some type of overrun condition check (a step instance taking longer than 2 ms for a 500hz engine). After checking Visual Studio help, it appears that the resolution offered by "multimedia timers" is limited to 1ms increments (1ms, 2ms, 3ms, ... ). timeSetEvent() can either call a user supplied function or set a user supplied event (handle) at the specified frequency.
Normally this real time thread needs the ablity to send messages to pending threads, and may reduce the overhead by only reducing the message rate, perhaps that 500hz thread is a racing game physics engine that only sends an graphics update message once every 5 events, reducing the graphics engine rate to 100hz.
In a corporate environment, generally you hire someone or a team with the appropriate knowledge as part of the team or at least as an assistant to the team. At this level, there's no point in wasting time to rediscover solutions to problems solved long ago by others outside the currrent team.
For an individual or small group, forums are probably the best place to get solutions and suggestions for deaing with to the type of issues that programmers run into. http://www.physicsforums.com is a good source for math, physics, and programming related issues.
I've witnessed the harm that can come from poor design. In one case, the team leader was opposed to a proper OS, and forced the evolving team (lots of turnover in this group), to use a round robin "scheduler", where thread switching only occured when each thread called an OS function to go to sleep and let the next thread run, until the OS cycled back to the first thread. Instead of messaging, the threads polled each other's gobal state variables to determine what to do next. It ends up as a long series of conditional statements, do I have an I/O pending? ... If yes, is that pending I/O now complete, if yes, handle the I/O completion ... if not, do I have an outstanding I/O request, if yes, do I have a buffer needed for that I/O request, if not, do nothing, if yes, then start an I/O request and set all the needed state flags, ... finally call the OS to switch to the next thread.
The thing was a nightmare to support. Even a minor change in one thread could impact the entire drive. One issue is that events occur out of sync with round robin scheduling, so performance is always compromised.
The other projects at this company used a proper OS, with prioritization of threads, combined with event and message interfacing. The team would define the threads and messages in a design document, then each thread would be implemented by own or two team members. The messages could be logged, which simplified debugging system level issues. Since the threads were isolated, it was very easy to track down and solve problems. For new projects involving a new CPU, the company would hire an expert to write the OS or they would buy an off the shelf OS for that particular CPU. One of my jobs was to implement an inter threading message interface layer so that the calls the threads made to send and receive messages would be independent of the actual OS being used.
I know this a bit off topic, but it's interesting to me, and might as well chat about something while waiting for the next release of LFS.
Regarding the poll, I'd obviously be in favor of multi-threading. I find it hard to believe that there isn't some form of multi-threading in LFS, so is the original poster sure that LFS doesn't implement multi-threading?
I wasn't. You had listed a few problems that can occur with multi-threaded applications, and I was pointing out the fact that solutions to those problems were determined decades ago (such as WaitForMultiple...).
The small sample code I provided would help explain multi-threading to any programmers interested in this, and my main point was on topic:
The main point here is that by using multiple threads, you eliminate the co-mingling of otherwise independent code.
Two issues with global variables. You want "atomic" (indivisible) updates of those global variables, so you use a mutex. Often some means to let other threads know that a global variable has been updated is needed, so here setting an event or sending a message is useful.
If the global variable is a structure, to reduce the amount of mutex time, one alternative is to use pointers to two structure instances, one structure is the "current" structure, the other structure is the "pending" structure. The "pending" structure is updated as needed, and after the update is complete, the pointers are swapped between "current" and "pending" structures, and the mutex is only used during the pointer swap time. An analogy would be graphics "tripple buffering" when v-sync is enabled.
The messaging alternative is an array of structures, and an array of messages with pointers to those structures, then use messaging between threads to update the structure information. In the gaming example, the car position data could be sent as messages to the graphics task, which would then use this information to update and output video frames.
On modern systems, ram is used for messaging, but db transaction history is always stored on a hard drive, as part of the recovery process. If hard drive fails, then the previous backup is restored to a new hard drive, and transaction history is used to "replay" all activity that occured since the last backup to restore the new hard drive to the state of the hard drive that failed.
Generally, messaging between threads is better than peeking or poking global variables asynchronously.
Spacing ?.. I don't understand the problem. Note that the important pieces of that code are ThreadFile0() and ThreadFile1(), which are small simple routines. The rest of the code is overhead to setup the threads and messaging, plus the normal stuff like allocating memory and opening files. mtcopy.c is just a template I use for creating multi-threaded apps. I didn't intend on using it as an learning example when I wrote it, but it's simple enough to serve that purpose, since it shows the overhead coding required for multi-threading, mutexes, semaphores, combined with linked list messaging routines that make inter-task communication as shown in ThreadFile0() and ThreadFile1() simple.