Jump to content
COMBATSIM Forum

peterpan69

Members
  • Content count

    18
  • Joined

  • Last visited

Community Reputation

0 Neutral

About peterpan69

  • Rank
    Second Lieutenant
  1. Hud in glide is really slow

    Two tips to increase fps in glide with dgvoodoo are: #1 Set the Screen Mode to 16 bits (not the texture depth, leave that at optimal). If you use windowed mode, then you can alternatively set the desktop to 16 bits. #2 Use one of the ZOOMed EXEs. In my case I find that the higher the FOV , the lower the FPS. The Zoomed EXEs are in fact smaller FOVs. ---------------------------------------- There are some scenarios that seem to have a higher impact on the glide FPS. Example: compare the FPS in the Taking Off Training Mission and in the Landing Training Mission I have not been able to figure out what exacerbates the fps lag in the landing mission.
  2. Some Observations on the FOV mods added in TAW 2.10

    BTW, Home Fries you wrote I am not sure if that is how TH2G works. I think TH2G renders, and splits into chunks that individual monitors can handle, instead of "stretching". Otherwise quality would be badly affected. The great thing about dgvoodoo is that it renders,not stretches, (via D3D) at the resolution that you set. Because TAW does not compensate for proportions at non native resolutions, the Hex Edit must scrunch the image horizontally, as you describe. The scrunch has to be by the right amount so the proportions "fall in place" once the higher resolution render takes place. I can see that there can be issues with "lines" ... like the hud text ... As a matter of fact, I have seen some issues with the edges of objects, becoming thick and blocky as they are drawn further away in the distance. I am not sure if this is a LOD issue or an artifact that becomes apparent on large screens, or a dgvoodoo problem. I am curious to see how does your hex edit looks like in my giant dgvoodoo window.
  3. Some Observations on the FOV mods added in TAW 2.10

    Let's continue with your assumption.
  4. Some Observations on the FOV mods added in TAW 2.10

    I don't know what I was thinking. I cannot glance left or right to read the HUD. This means it can be obscured by the BEZEL. This leads to yet one more issue. if you use a widescreen monitor on the side and a regular 4:3 aspect monitor in the center, the hud has to be even smaller, because the dgvoodoo window is not centered. the dgvoodoo window is pinned at 0,0
  5. Some Observations on the FOV mods added in TAW 2.10

    Looking good... and moving fast I am trying to understand what you are seeing on the regular800x600 screen... Did you capture the shots at 800x600 and stretched them horizontally to 2400? Did you cut the bottom half of the captured shot or did the image render on the upper half of the 800x600 of the screen and you stretched it out vertically? My top concern, from my testing experience... is that the aspect ratio of the 3D world has to be correct. (I take that the aspect of HUD can be changed separately) If there is a too much zooming in one axis... the moment you roll the plane, a one mile wide runway turns into a one and a half mile wide runway. In a small monitor it might be annoying, but across three monitors, it is a formula for motion sickness. I am glad to see that you can play with the position of the HUD. I am not so concerned about keeping the HUD or the data in the center monitor, as long as it is visible on a monitor. For example, the radio menus will always appear on the left monitor. I think that is just fine. Because the HUD moves with the pilot view, I can glance left or right in case part of the HUD is partially obscured by the BEZEL. Not an issue. Problem is if the HUD or the data are cropped outside of the view window. Are the stand alone MFD views usable with you Hex Edit?
  6. Some Observations on the FOV mods added in TAW 2.10

    Houston we might have a problem. Good thing you asked. if I set dgvoodoo at 800x600, it cannot span across three monitors. The dgvoodoo window cannot be resized. (stretched). The dgvoodoo window does not have a frame or a title bar or anything. It's pinned at 0,0. What I meant is that the dgvoodoo can be arbitrarily large. But it has to be configured in dgvoodoosetup at that specific size. I used a 2400x1200 resolution in dgvoodosetup, so the dgvoodoo window overflows horizontally onto the second and third monitors. The bottom part of the image is "discarded" below the monitors. -------------- About the size of the HUD... The TAW 2.12 hud extends onto the left monitor (which is a 800x600 normal aspect ratio) about two and a half characters, using a 2400 resolution To get and idea of what I am looking at, you can set TAW in wideview mode ("K" shortcut) and cover the bottom half of the screen. You can divide vertically the remaining portion of the image in thirds, and that is what each monitor displays. (at 800x600 each) You will also immediately realize what part of the HUD is not visible any more. --------------- Just let me know if you want me to test something.
  7. Some Observations on the FOV mods added in TAW 2.10

    Great news! I think I have not fully understood the way the hex edits work, but I will be glad to test the results of your magic.
  8. Some Observations on the FOV mods added in TAW 2.10

    Forget SoftTH and TH2G for a moment. I think we are moving a bit too fast in the direction of Hex Editing. (I admit I originally suggested this). ALL AND ALL I think that we already have a solution for Multi-monitor TAW, withouth THG, for anybody who has three monitors with similar vertical sizes, enough video cards outputs to attach them all, and trackir. Here is why... The Very good news, it is possible to run TAW with dgvoodoo "windowed" in an arbitrarily large window, (for example 2400x1200 - just tested it successfully). This window will span across several monitors over a regular extended desktop. Only the portion of the window that fits in the visual area of the desktops will be visible. For this however, it is necessary to "convince" dgvoodoo that such arbitrarily large resolution is somewhat possible, otherwise the resolution will not show up in dgvoodoosetup. I have accomplished this in two different ways: Option #1 placing SoftTH modified d3d9.dll in the program's folder and doing proper configuration. (Notice that I don't use SoftTH for the widescreen effect, I just use its dll to trick dgvoodoo) (Notice that I don't use THG either, I just have an extra video card for the extra third monitor and have extended the windows desktop to it) Option #2 using Nvidia's ability to create a virtual single monitor, by joining the two outputs of a single video card (this is called a horizontal span, and it shows in dgvoodoo). IMHO Option #2 is a no-go because is limited to two monitors only, and you end up looking at the bezel, in between the two monitors, while trying to lineup the plane for landing. Because TAW stretches the image to fit the arbitrary window size used by dgvoodoo, the resolution of the dgvoodoo window has to be carefully chosen to keep the proportions. My guideline is the "circleness" of the rings in the MFDs. I think 2400x1200 is an OK resolution, because it can fill up to three monitors at 800 pixels wide each. I don't know what is the perfect aspect ratio of the widescreen version of TAW, but the vertical at 1200 looks just fine. It can be changed. Therefore the problem is not how to fill the screens, nor how to keep the proportion nor how zoomed-in or not the cockpit looks. The zoom factor actually looks acceptable to me in a 22" set of monitors, using the WIDE view from TAW ("k" keyboard shortcut). The visor at the front of the cockpit shows at 9" wide or so. Here is however the minor problem that I still see... The cropping of onscreen info (Engine level, some hud info, time, etc), and the cropping of the standalone MFD views. Because in this display mode, only the top 600 pixel lines will be visible. (at 1200 vertical, 600 is 50% of the TAW screen) To migigate this, it is possible reduce the vertical resolution to lets say... 1024... which allows to see again the weapon choice, fire mode and perhaps the waypoint data... (600/1024 ~ 60% of the TAW screen), but it still misses engine levels, AirBrake status, which you HAVE now to check by looking at the bottom MFD. Some might argue that this adds to the realism Clearly it is not good to reduce the vertical size, as it starts to become noticeable on the aspect. So the two half a million dollar questions are... can we MOD the onscreen info at the bottom to appear a bit higher on the screen? If not, it should be noted that it is still possible to glance at the bottom MFD with TrackIR to get the data. and/or perhaps can the HUD be modded to look smaller while still centered? If not, I use the original TAW HUD which puts more info in the upper portion of the screen at is FPS friendly. If the mods are possible, they would need to be FPS friendly, because at this resolution dgvoodoo is already struggling. If not... ALL AND ALL I think that AS-IS this is still a viable Multi-monitor setup of TAW, for TRACKIR users willing to glance/zoom at the bottom MFD as needed. I won't promise a video, but I'll see what I can do to show the proof of concept in action.
  9. Some Observations on the FOV mods added in TAW 2.10

    I got a new resolution that works without the SoftTH complaining about it. 2360x1280. It is 18.5:10, but I had not noticed the vertical stretch until I wrote this post.The good news is that I gain a bit of horizontal real estate. I have turned on 8xS AA and 16x Anisotropic, and it is starting to look pretty good. Framerate needs a new video card I guess. My GF7900 is maxed out. Unfortunately the "window" generated by dgvoodoo, does not appear to have a frame and it cannot be moved nor re-sized. The dgvoodoo window will be displayed on the desktop at 0,0 of the PRIMARY monitor, or the adapter that is chosen in the dgvoodoosetup window. The portion of the window that does not fit on the three desktops, remains out of the field of view. The limit of 600 in the vertical resolution of the monitors produces a cropping of about half of the rendered frame. The vertical resolution of the monitors needs to be fixed at 600, otherwise there is a misalignment of the images. The TAW interface sets the primary monitor at 800x600, and the others need to follow, the vertical size. The horizontal resolution of the monitors needs to be 960 for the widescreen monitors and 800 for the non-widescreen to keep aspect ratio. Using a 19" regular monitor and two 21,5" widescreens, I get approximately 42 inches of horizontal field of view. Using the regular monitor on the left (narrower), a widescreen in the center and a widescreen on the right. This leaves the HUD almost at the center of the central monitor. The pitch ladder and the compass are just fine. Eventually I have to slightly move the head up to be able to read the heading. The NORMAL view, acts now like a ZOOM. It is actually pretty handy when trying to line up the runway. Otherwise I use the wideview quite comfortably. (although it has a framerate impact) I can actually read all the MFDs from the virtual cockpit, no need to look at them one by one with the NUMPAD keys. Using the NUMPAD views of the MFDs is useless in this mode, because the bottom half of them are not visible. I still need to figure out if I can survive this.
  10. Some Observations on the FOV mods added in TAW 2.10

    Good, Here is what I have found today... I can run a very large dgvoodoo window of TAW at 2040x1280, and display it across three monitors set at 600 pixels height each. The result is positive. The aspect ratio is preserved because 2040x1280 is ~16:10. Using TrackIR it is easy to pan as needed to see what is out of the immediate field of view. In Wide View ("k" shortcut), here is the visual field, looking ahead. Also in Wide mode here is a shot of the MFDs Now in "normal" mode, a closer view of the MFDs (at this cropped resolution Normal acts more like a ZOOM) And finally, here is a shot of the side view, using the WIDE mode. Obvious problems are, low framerate (dgvoodoo at 2040x1280 is slow), a few artifacts on the textures (mesh-like stretching I guess) and the HUD is cropped so it is not possible to read the weapon selection, (info is out of the visual field) Other than that, I think it looks promising. To set dgvoodoo at such high res I had to use dgvoodoo in directx9 mode with a modified d3d9.dll where I could add "custom" resolutions. I used the d3d9.dll from Kegetys SoftTH. Kegetys SoftTH I had tried to use SoftTH itself for multi monitor without success, but in this case, I can use their dll to add the custom resolution mode to dgvoodoo. One final issue is that the TAW launcher crashed in the background while trying to dismiss the warning from SoftTH about the ID of the displays. Nonetheless, after dismissing the SoftTH errors, dgvoodoo kicks in in the high resolution mode with the results shown.
  11. Some Observations on the FOV mods added in TAW 2.10

    Yeah, the works of Shakespeare in Octal instead of Hexadecimal )) Talking of monkeys... I must have had my brain monkeys write my posts because I would not ever imply you did a poor job. I don't agree that you came up short. On the contrary, you have done a hell of a job. I agree that multi monitor requires some sort of zooming out, and I did my tests with the "Wideview" ("K" keyboard shortcut). It helps.
  12. Some Observations on the FOV mods added in TAW 2.10

    I agree... nice resolution choice. How about a playing TAW in a multi-monitor setup? I can launch TAW using dgvoodoo in multi-monitor in windowed mode. Unfortunately the horizonal stretching is very bad. Would it be possible to create one more hex edited version with the right proportions (FOV?) for... lets' say... (800x3)x600 resolution? That seems wide enough for three regular aspect monitors , and it would equally work with a mix of regular and widescreen monitors, or an all-widescreen setup. Wishful thinking? I was trying to make sense of the editing from mlracing and I got completely lost. I only came to the conclusion that the "infinite monkey theorem" could also be applied to hex editing http://en.wikipedia.org/wiki/Infinite_monkey_theorem
  13. Using trackir to control the POV Look function

    Don't know about Version 5. I am afraid I will have to wait until version 5.1 of Trackir Software, because only then Naturalpoint will include support for the old HW ( I use a Trackir 3). There is a short thread in NaturalPoint's forum about Longbow 2 Trackir support using Trackmapper. Longbow2 and Trackmapper thread at Naturalpoint forums
  14. Frame Rate Boost in Glide

    25 FPS.You seem to be doing just fine. I like the Z800. It is very immersive and not too clunky. When using it, at the beginning you have to be careful to make it comfortable and keep the correct eye alignment but once you figure out what works best, it is not a problem. Too bad the resolution is only 800x600. But the OLED displays are quite bright and crisp. I still prefer to use trackir for headtracking because the Z800 head tracking lacks support in games and mouse tracking is not a great option either. It is easy to setup Z800 and Trackir simultaneously. With three DLPs in S3D, it seems as if you will have your own private IMAX theater Good luck with your project. I wish I had that much space to spare right now.
  15. Using trackir to control the POV Look function

    I have to admit that EF2000 had excellent view support when it came to the market. That's what in fact made me think of trying to get the Trackir working somehow. Keys can be mapped to specific positions of the TrackIR yaw and pitch axes using a program called Trackmapper. I think you probably know it. I use Trackir software version 4.1 Build 36 on a Trackir3 PRO, and I have tested successfully Trackmapper with it. It works particularly well with the snap views of the instruments. I look down left, down right or down center and can see the MFDs, I center the view and I can use the NUMPAD8 to recenter my view. It even works well with the status lights, the IRST and the Artificial Horizon. The first problem I have with the snap view keys is that there are only YAW keys,no pitch snapviews. Not good for dogfights. The second problem is related to Trackmapper capabilities. There are only two keys for the YAW snap views, NUMPAD9 and NUMPAD7, and to get a specific snapview, the corresponding key must be pressed two,three or more times. Instead of single key for a given snap view (e.g. key1=45 degrees, key2=90 degrees, key3=135 degrees) Trackmapper allows to send several keys at a given position of the trackir pointer, but apparently they cannot be the SAME key twice or more times. Aside from that, I think that EF2000 is also picky in its handling of keys. I have to send both Virtualkey Codes and DirectInput Scancodes for the keystrokes to be recognized. Overall I think that POV is a better starting point for TrackIR. But hey, if someone figures it out with keys, I take it. I have not read enough about how TrackIR support was added to TAW. I will look around, maybe I can get some ideas.
×