beugnen

anytime buddy, happy simming!

hmm tricky...maybe: * cpu throttling due to overheating (which is activating more when BS has focus) * when the game does NOT have focus, do you still hear sound from the game. if there is no sound that might be the reason for no stutter. that there is some issue with sound?

yup that's basically correct. a 32bit OS is limited to integer ranges up to 4,294,967,295 - which just happens to be 4GB. now here i refer to amount of memory available to the OS, it does not necessarily mean the max memory available to a single app. virtual memory is much more complex now then i last looked at it in my c++ days of 4 or so years ago. to make things more interresting, vista has 'changed' the way memory works. a posting from the devs from PMDG 747-400x raised this on their web site. http://ops.precisionmanuals.com/wiki/747-400_FSX_Technical_Specs_&_Performance Depending on your add-in hardware and how it maps to the upper physical address space, you will end up with: 4GB - reserved-by-hardware[1] = memory-available-to-you [1] the dreaded 32bit TAX! i dont think its always the case that a 1GB vid card will always pinch 1GB of RAM from your base memory. before i moved to vista64, my dual 768MB cards left me with a total of 3GB - so it seemed that not all memory is mapped. moving to vista64 and now i have all my 4gb. yay! :) i suspect each system will vary happy simming! EDIT: doh! as darklighter said. did not see his reply ;)

windows is ONLY as reliable as the worst written driver in much the same way that responsiveness in Windows 95 was only as great as the worst written application. that's why apple is generally so much better, they make all the hardware and drivers. hardware manufacturers are reluctant for many reasons to have their drivers WHQL for every release. so just because you have the latest video card from brand xxx, chances are it has not passed microsoft testing and you are basically a beta tester. so if you have a dud video, audio, raid, motherboard, or usb driver chances are your game will go KABOOM!

that's good news. yes BS seems quite modest when it comes to textures so it would have low demands on gpu memory i guess :thumbup:

i just got the trackir 5 and it has no human noticeable delay on my system. i dont think its fair to say 'everything that is processed digital has delay' - though technically true it sounds a bit like scare mongering :thumbup: sure it might take some devices 10 ms to process but human reaction time is no where near that discrete. thats like those die-hards fps fans wrongly thinking that a cordless mouse is better than a blue tooth one. i would argue that even some forms of analog of 'latency'. radio communications for example are not instant. even the poor human brain which i dont think classifies as digital has latency. take the example of driving a car. the latency involved in seeing a pedestrian step out onto the road to the time you press your foot on the brake. this takes time and is subject to other effects such as driving whilst drunk. these reactions take considerably longer than 10 ms. :thumbup:

runs fine on my Alienware Area-51 7500 Specifically: Alienware P2 Chassis - Alienware® P2 Chassis with AlienIceT 3.0 Video Cooling Space Black Alienware P2 Chassis Lighting - Alienware® AlienFX® System Lighting Alienware P2 Chassis Cooling - Alienware® High-Performance Liquid Cooling Alienware P2 Chassis Dampening - Alienware® Acoustic Dampening Power Supply - Alienware® 1000 Watt Multi-GPU Approved Power Supply Graphics Processor - Desktops - Dual Graphics Processors Dual 768MB NVIDIA® GeForceT 8800 GTX - SLI Enabled Video Optimiser - AlienAdrenaline: Video Performance Optimizer CPU - Area 51 7500 - Intel® CoreT 2 Extreme QX6850 3.0GHz 8MB Cache 1333MHz FSB RAM - Area 51 7500 - 4GB DDR2 Performance SDRAM at 800MHz - 4 x 1024MB Motherboard - Intel 7500 - Alienware® Approved NVIDIA nForce 680i SLI Motherboard OS - Desktops - Genuine Windows VistaT Ultimate 64 OS Enchancements - Without Media Center Remote Control or TV Tuner HDD - Extreme Performance (RAID 0) 500GB (2 x 250GB) Serial ATA 3Gb/s 7,200 RPM w/ 2 x 16MB Cache HDD2 - 500GB Serial ATA 3Gb/s 7,200 RPM w/ 16MB Cache Optical One - Single Drive Configuration 20X Dual-Layer DVD±RW w/ LightScribe Enthusiast 1 - Dual High Performance Gigabit Ethernet Ports Enthusiast 3 - Creative Sound Blaster® X-FiT XtremeGamer High Definition 7.1 Audio Keyboard - Logitech G15 Mouse - Logitech MX1000 Removable Storage - Alienware® 28-in-1 Digital Media Reader / Writer Removable Storage - 3.5" 1.44 MB Floppy Disk Drive Game Controllers - Saitek X52 Pro Flight Control System; TrackIR 5

FSX is CPU bound just like BS but for different reasons. though the flight model in FSX may not be as complex; weather simulation over surfaces is not accurate [1] as blackshark, both find the cpu is the bottleneck and not the gpu. so where does all the cpu go in fsx? in the huge scenery, dynamic scenery, AI traffic et al - a known frame-rate killer, something sadly that the gpu does little about. for an extensive analysis of fsx performance, google 'fsx sli' or check out the following article. http://enthusiast.hardocp.com/article.html?art=MTI2Miw0LCxoZW50aHVzaWFzdA== basically on a sli 8800 gtx, you can happily change AA all the way up to 16x before you notice a difference in FPS. "What this shows us is that with BFGTech GeForce 8800 GTX SLI we are not GPU limited in this game until we hit 16X AA, so basically 8X AA is for free, at least on the Intel platform." [2] [1] PMDG comments on fsx (not BS) [2] http://enthusiast.hardocp.com/article.html?art=MTI2Miw0LCxoZW50aHVzaWFzdA==

i'm not sure that is entirely correct. apart from the benefits of a 64-bit cpu that offers performance gains there is also speed gains from caching from increased memory. moving from vista 32 (where i could only access 2gb of my 4gb of ram) to vista64 where i could now access the full 4gb, BS had significantly shorter load times. not only that, disk activity dropped if loading missions with the same or similar resources as it had been pre-cached by windows. :thumbup: EDIT: i assume your original post was just about BS. i admit coming into this forum late and cant quite understand if it is BS, TS or vent related.

not in games, but after watching an action film with lots of car chases, i feel like im in the film still when i leave the cinema and get back into my car hehe. its probably something to do with the eye being tricked into motion but the inner ear isnt fooled. thats why i cant read a book in a car as a passenger, i get car sick. the eyes see no motion but the ears sense it. brain gets confused, thinks there is something wrong and defaults to throwing up to rid the 'germ'.

no problems buddy sweet! thanks :)

i loved microprose. the first pc game i bought was Microprose Tank Platoon and thought it was fantasic. the ability to move to different stations within the tank, give orders to other tanks and call in air strikes and recon was well done

well, theoretically 64 bit is more than allowing for more memory, it also increases the word size of the CPU for one thing allowing it to store larger integer values in registers which is a boon for calculations. where previously you may have to break up a number into multiple memory locations and resort to trickery to achieve the same result albeit slower. hopefully they have increased the size of floating point registers and increasing floating point precision which has caused issues in the past. for example, in my motorola 6809E assembly programming days, i thought it was pretty neat the 8-bit CPU with 8-bit word could mulitply two 8-bit values and shove the result in a single 16 register. that allowed for a max size of 65535 unsigned or -32768 --> +32767 signed. what fun we had. it even had a hardware divide instruction which took a significant number of cpu cycles. then along came the motorola 68000 - a 16 bit cpu with 16 bit word[1] and so many address bits i dont remember. the registers are now all 32-bit instead of 16 in the 6809. now suddenly we could store much larger values and perform much more trickery. with each incarnation, CPU cycles for an operation may change or a new instruction is introduced that replaces a few steps in the old cpu. now apply this to the move from 32 bit to 64 bit cpu and you'll get an idea. the above sounds like a pro when you consider a CPU-bound application like BS. i think i know the article you mentioned, i've been madly trying to find it.

As a developer, its not really true to say that making an app multithreaded will generally add two to four times development. sometimes doing things in a thread solves some problems and can make application time shorter. the thing to remember is that many developers do not understand threads and start using them willy nilly and get themselves into a corner. e.g. race conditions, thread safety, attempting to update the UI from a worker thread, spawning a thread from the main thread and then waiting on it (defeats the purpose). indirectly it can. logically, you place resource loading into another thread and perform asynchronous IO freeing up the main thread. if you used just one thread then it would have to wait for the memory, at least with threads you can do something else at the same time. ya thats pretty easy. if you're a good displined c++ programmer your typedefs for pointers and such won't change really. agreed. rewriting an application to use threads that did not use threads in the first place would be a nightmare so i agree with you there. then again rewriting an application is always a nightmare. though it does not require rewriting every routine. some parts of the application will never benefit from being made multithreaded, re-written in parallel et al. :thumbup:

i say stick in there rabbit. there appears to be much calculation going on in BS, calculations that can easily be optimized through-out the life of the product. e.g. better use of multi-core or even just optimizing code. even though something as complex as a flight sim may use extensive use of a cpu, gpu and ppu does not mean they are being used optimally. maybe bs is, maybe it is not. though there was not much in the way of physics in say x2 the threat, there was much in the way of calculations in the game given the hundreds if not thousands of ships in the game. x2 sadly initially appeared quite cpu bound but was fixed to an extent in later releases. the same can be said for games that make use of a gpu. just because a game utilises one does not mean fantastic frame rates. just take a look at dungeon siege 2 and supreme commander, both titles that use little or no physics but plenty of gpu and yet lousy frame rates. sometimes a 3d engine that was suitable for earlier titles is inefficient for later derived ones. being a humble programmer myself, i can not say for certainty what is happening in bs but what i can say is that many games go through teething problems in early incarnations only to be rectified in later releases. such fixes sometimes are the result of observations made by internal QA as well as enthusiast game owners. you never know, the high cpu usage may be the result of a forgotten thread.sleep()...just kidding. safe flying my friend EDIT: damn new-post-email-notification. i've realised ive replied to an older post, oh well