Roman G

Yes, it is possible to display for example 1920x1080 signal on let's say 1280x1024 monitor - but as far I know most of TFTs don't support it. Monitor basically could take 2.75 (or whatever the downconverting ratio is) source signal pixels and display them as single pixel on monitor. It can use the same algorithm as almost any slideshow viewer uses to display pictures from your 5-megapixel digital camera on your 1.3 (or whatever) megapixel monitor. However to not have "shivering" pixels in video it requires quite a processing power - that's probably why it is not common. If you are thinking about it - the monitor is doing antialiasing for you - taking oversampled picture and downsampling it - so if your monitor support it then you could use it instead of turning on antialiasing on your graphics card. There are also external up/down-converters you could use - such as ones here: http://www.dvdo.com

1920x1080 aspect ratio is 16:9 (of course ...)

Buckler. Just put the russian version on the shelve and go buy English version. Yes, you wasted a few bucks, but you can easily recover the "loses" if you skip a lunch or two (plus it will be good for your health :) )

Agree with opinion that x-plane is missing low-level detail like trees and so on. That is what is actually most important to me (regarding graphics)- I am usually flying below 3000 feet. High altitute mountains mesh however seems better than the one in LoMac. Despite x-plane's defficiencies - it is pretty amazing achievement considering that x-plane is one-person-team project. Here is interesting article on Popular Science about the X-Plane's developer: http://www.popsci.com/popsci/aviationspace/78ec5b4a1db84010vgnvcm1000004eecbccdrcrd.html

Thoughts ? 800 x 600 resolution is too low. 200 : 1 contrast ratio is too low. Bundled Head Tracking is most probably not supported by LockOn.

Cosmonaut ... TrackIR is basically infrared-light sensitive WebCam with small infrared illuminator. The illuminator illuminates reflective dot(s) which you have to wear on your head. For just look left/right/up/down TrackIR needs just one reflective dot. For 6DOF (head position + rotation tracking) it uses three reflective dots. Based on where those three dots appear on the IR WebCam picture it calculates head position and rotation ...

Hey Caretaker ! Just want to remark that I see some room for improvement in 6DOF and cockpit modeling there. Also you are still ignoring wishes of western community - I don't know why you chose those strange planes instead of finally giving us F-16 or F-18 ! ;) Nice to see you around again ... Roman

Excelent video! Cant wait for 6DOF !

It is not question of processing power but question whether that hardware power will support particular physics needed for AFM, plus support it by SDK API and drivers. ... even if GeForce 7800 GTX has plenty of calculating power you still cant use almost any of it for voice recognition because it is just not built for that task ...

I think it could be really helpful to offload bullets balistics and collision detection to hardware. It could help in situation when there is a lot of bullets in the air and also offload some processing used for radar modelling. The card physics probably won't be good enough for Advanced Flight Model - but should be good enough to improve land & sea vehicles physics.

I didn't want to go that far - but, yes - why this is not part of every larger passanger plane ?

OK, it does sound like pilots were extremely poorly trained - which is quite against all popular believes and shocking. Other thing hard to believe is that in this century an commercial airliner alarm system is communicating information to pilots by buzzers and lights. How expensive it would be that instead of siren sound the alarm system would SAY "Cabin Pressure Low, take oxygen mask NOW !" and suggest what else is the pilot is supposed to do ? This could also help scenario where for whatever reason an amateur is flying the plane (in the event where both pilots just died of heart-attack or whatever else). And why autopilot takes plane to 35 thousand feet (even if it is programmed so) if cabin pressure is low ? Why opening main oxygen valve is manual procedure and why there is no warning when valve is closed and the airplane is in the air ?

Yeah, ... the fire smoke in LOCKON would need some overhaul to look more real. LOCKON shows high-altitude airplane vapor trails tens of miles long but for some reason they restricted ground fires to tiny puffs ...

Very nice work Amraam ! Thanks !

My pick for best Lomac movie is "Maximum G". There are many other very good ones ...

This thread wouldn't be here if StarForce wasn't such a poor piece of software. Issue #1 - they chose to delete your activation key info from registry once you uninstall FC. (this actually is partly problem on ED-side too). If they chose not to do that then Buzzu would still have a couple of activation left. Those who don't plan to install FC anymore would have about 1kB of their hard disk wasted - which with today's HD prices cost about 0.001 of a penny. For those outraged by this cost ED could provide tool to completely remove activation key(s) from registry instead of providing tool to back-up activation key and then restore it. Issue #2 - SF is supposed to bind your FC copy to particular hardware. Why then they chose to use things like "computer name", "hard disk label" in SF hardware key? Computer name and disk label are not hardware attributes and they are in category of things I can change a couple of times per day without thinking that I should re-buy any software installed on that PC because of that ... Issue #3 - why HKEY_CURRENT_USER registry hive is used for storage of SF activation keys ? For this reason SF asked me for SECOND activation key two minutes after I installed FC and activated it. Why ? Because I install things logged in as Administrator, and then run (any) software using different (non-admin) windows account - this is good for your system health as it makes it harder for viruses/spyware to get in. So basically, each time you log into computer with using different login name and try to play FC - SF asks for new activation. This problem wouldn't be there if SF chose to use HKEY_LOCAL_MACHINE registry hive instead. Issue #3 - why SF needs to be installed as a system driver (I asked this question before but nobody from SF or ED bothered to answer) ? I am quite careful about security vulnerabilities - and installing a driver from unknown software developer bothers me a lot. A lot of people raised their security concers about SF and it's prior history of security vulnerabilities even before FC was released. A lot of these concerns could be shut off if SF would not require admin priviledges to install or run.

I thought that flight suit is equipped for "that" ... (?) I mean, it is not surprising that sometimes you must unexpectedly "go". Wearing Pampers would help .... As far I remember they (Pampers stuff) were invented for the Apollo moon missions ...

I think what SpongeBob means is movie rendering way beyond current Lock-On max settings (or at least that is what I understand as "photorealistic" ). For example using better tree, buildings, and maybe plane and vehicle models, smoke effects, soft shadows, display all objects (up to one pixel big) instead of popping them up based on distance, maybe throw some rocks and grass around, more bumpmapping and reflections. For example PovRay raytracer could be used for such rendering - but that would presume that ED would make scene exporter to easily readable PovRay format - which is unlikely since ED like to keep things proprietary.

My suggestion was not targeted to improve LOMAC performance on multi CPU boxes nor to take advantage of multiple CPU/cores. My suggestion would actually LIMIT lockon to run on one CPU/core only. What I am suggesting is instead of using external 3rd party's "ProcAff" application as found by HUQ - the ED should make use of the SetProcessAffinityMask function to achieve the same "fix" - as an integral part of LOCKON (without need to download and run external 3rd party program) - at least until they truly fix the problem or make LOCKON take advantage of multiple CPUs. Sure it can. The thread gets interrupted on one CPU - it goes into suspended mode - when windows decides that it is time to run the thread again it can give it to DIFFERENT CPU to run it. That means that whatever was in previous CPU's cache needs to be replicated on other CPU's cache - which is bad. This actually might be reason for HUQ's problem ...

There is "SetProcessAffinityMask" function in Win32 SDK which allows programmers to specify on what machine processor(s) is process allowed to run. If LOMAC is currently having problems on multi-processor/core CPUs then I think ED should make use of this function to fix this problem in the upcoming FC patch.

Thanks to everyone trying to help me with solving my problem ... o I am quite sure I don't have bad potentiometer problem - I don't have target designator binded to joystick axes - I binded it to joystick buttons - those should not generate "noise" as potentiometers tend to do - and CH is supposed to be higher quality joystick anyway (well - at least judging from the price ...) o I am sure I am not exceeding bank angle - I see the target in mid-bottom part of HUD - mean that I am within Shkval gimbal limits - and even if I was not - the target designator should not move on it's own ... o I am not flying too low - nor the target is obstructed - my altitude is more than 1000 meters above terrain. And even if the target get obstructed - that should cause target designator to just stop tracking and not to move accross the tarrain at speed about 200 meters per second ... o I have correct size of the target - 10 x 10 m - which is about the size of tank/truck. I did a bit of investigation. I unplugged my joystick, then throttle, then pedals. After I unplugged the pedals - (with joystick and throttle plugged in) the problem disappeared. I plugged the pedals back - the problem was there again - even if I have NOTHING mapped to pedal axes. Since I like to use the pedals - I tried to "fix" my problem this way - I defined 100% dead zone for two pedal axes which I am not using at all, and small dead zone for the axis which I am using for rudder control. This helped a LOT. From that moment - I see the designator problem very rarely - about once per 10 LOMAC sessions. My "solution" indicates that there is some bug in LOMAC code which parses the joystick data - it seems that unbinded joystick controls are able to affect unrelated LOMAC functions (like the targed designator). Also my problem and solution seem very similar to problem and solution of people having Zoom in/Out control problem.

Not sure what you mean ... you mean mesh for buildings data or mesh for the terrain under the towns ?

I think the data ammount problem can be quite easily solved. You need to do something similar as SOLDNER game did (soldner is otherwise IMHO quite failed game but the terrain they used was OK). http://soldner.jowood.com/?RubrikIdentifier=961&lang=en Also you can take a look at this link: http://web.interware.hu/bandi/ranger.html I suggest you download the demo there - if you have a NVIDIA card (GeForce 3 and up) I guarantee that you will be very impressed how much amount of data can be rendered by 3MB package (which includes data & the program to run it). The trick behind the engines above is to generate/refine the detailed data in run time using noise functions. The perlin noise (or other noise generators) has advantage that you can achieve about infinite data detail - depending how much CPU time you are willing to spend. For terrain far away you generate less dense data - for close terrain you use more noise samples. This technique is I believe used in other engines - I really doubt that for example Far Cry is reading the grass positions data from a file - I think it generates it on the fly using some parametrized noise pattern. My thinking about this "joined games" was mostly in the same line as Weta43 wrote. Basically each game could use it's own rendering engine. When flying LOMAC plane then regular LOMAC's engine would be used. It would not render things displayed in FPS - like grass, rocks, furniture inside buildings, and perhaps not even soldiers (except SAM soldiers). When playing the "OFP part" - the OFP engine would be used - working about the same as if LOMAC wasn't there. When LOMAC rendering engine would be used - the only OFP component running would be ground units and overrall "war picture" controlling code. The control of air units, missiles, radar and SAM sites would be in LOMAC's control - LOMAC would feed the OFP dynamic campain engine with whatever is the result of the air war. Similarly - when playing the ground war - OFP rendering engine would be running - LOMAC would be controlling only the air/SAM units in immediate player's vicinity. I guess this could be running pretty nicely on multicore processor - each "subgame" running on it's own core. As Weta pointed out - one issue would be load times when going from air to ground war and back. Since most of the load time is loading of terrain and textures and objects - this load time could be greatly reduced if both games used the same terrain and object structures (which is, well - unlikely).

What do you mean ? Map location or it's size (or something else) ? Yes, definitely it would not be easy. Biggest problem I see is whether (any) two independent companies could overcome their disagreements and design the game-intercommunication-interface which would be needed for such a project (plus agree on lot of other things like who does what and who pay for it). Technically it would be also challenging - but I don't think it's impossible.

But that is not what I am talking about. You are talking about single game produced by single company. I am talking about two (or more) games which are compatible with each other, each of these games is produced by different company - each game sold separately and playable with or without the other game. Each company excels at what they do best - but when one company tries to do everything then they usually do not excel in anything since they don't have resources for that. If games from different companies would be compatible (so you can play both of them in the same time as a single game) - you would get a game which excels in all areas where those other individual games excel.