It's been about 6 years since I had this idea, and about 6 years since it got put into the loft.

A lot has changed in my life since that day, but I might have time to consider dusting off the notion and starting over. I think might just do that.

If you want something done...

I had to head home early from work today due to what feels like heat exhaustion. As I was resting, I had mad fever dreams about how best to fix the flickering from UltraMon.

After some heavy research, It seems to be a symptom of DirectX - after all, I'm trying to capture hardware overlays. I decided that I'm using a lot of system resource, and an imperfect solution to resolve this issue. In response, I've developed my own little solution.

I've posted the Source Code below. Though the interval on the timer should be 50, not 25. It seems quite simple, but it's the result of a few hours of research and coding. I began with BitBlt calls from GDI, but ultimately settled on Graphics.CopyFromScreen() (basically the same thing, but a lot easier to code).

I added in some command-line parameters to override the hard-coded screen coordinates if needed.

Finally, the application presented the same problems that Ultramon did, in that the display flickered every few frames. As a workaround, I recorded the pixel values of random locations for every frame. This allowed me to identify which frames were blank. As I'm now using my own code, it was simple to ignore these blank frames.

The end result is a constant output with far less flickering, and far less impact on system performance. The frame rate is sporadic, only updating approx 2/3rds of the output desired, and there is no hardware overlay. However, the dimensions of the output are now almost perfect, and it's a lot better than a constantly flickering device. As a nice bonus, I can now "activate" the display by launching a single application - currently it's in the Windows Startup folder!

I've been looking into Direct X Hooks to capture the true 3d output. This would be the best result, and tests with SlimDX on my desktop were very promising, however there seems to be some comparability issues on the gaming rig, so for now, this will have to do.

Itsy Bitsy Teeny Weeny.. (Oh Yeah!)

Since my last post, I've spent a few pennies on eBay to get the project moving, but have hit yet more snags.

Firstly, I wanted to  fix the missing bracket on the video card. I also had an idea of where I'd be going with the targeting computer, so I opted to replace the card entirely, thus swapping the S-Video for an RCA port. There's not much between the options, but as the card (which, by design was another GeForce 7200 GS) was listing at less than £3, I didn't see any harm.

At the same time, I was hoping some extra Memory would alleviate some video issues, so replacing the 256MB module with a 1GB was an easy choice.

The odd thing is, the card needed new (older) drivers to function correctly,
despite the only difference being the presence of the RCA port instead of S-Video.

Now that I had some of the annoyances cleared up, I located my Projector, an old (but still good) Epson EMP S1H. I haven't tested this yet, but I was able to ascertain the maximum resolution is 1024*768. As I intend to use this as the main display device, I've had to drop the in-game resolution from 1920*1080 accordingly. The main issue here, besides the massive drop in display quality, is that the projector has a pretty long throw, so I need to check out the room dimensions to see if this will work as intended.

Last used to throw Pirates of the Caribbean onto a sheet in the Garden!

 

 

Finally, I took the (admittedly cheap) plunge and got myself a 4.3" TFT monitor. At £15 including postage, this little beauty arrived in less than 2 weeks. I have to say, I'm actually really impressed with this. It supports both PAL and NTSC right out of the box, has two RCA video inputs, and automatically turns off with no signal. It's light and at first doesn't feel like it'd last a week, but it's surprisingly well made. It tends to have a bit of a fit every time the resolution changes, but it's not really built for what I'm doing, and I don't have to adjust ANYTHING, it just gets right on with the task.

The Sun Visor, thankfully, just popped right off.

 The monitor is built for use in-car, and as such, the supplied power adapter isn't of any immediate use to me. However, as the device uses a simple DC-12v supply, I was about to jury-rig the cable onto the 12V Rail of a spare MOLEX adapter. As it turned out, whilst looking for an RCA cable, I stumbled upon a spare 10.9v adapter. This does the job just fine.

It's taken me about 4 hours this evening to get everything up again. Every time I change hardware, or system settings, It seems I have to change the display settings, reconfigure the joysticks, and generally piss about. I hope it's worth it.

4.3" TFT cloning the in-game target display.

The two other issues I've hit now, are that the aspect ratio is a little off, and the monitor has a serious flickering issue in-flight. The Ratio I can deal with, the flicker is a deal-breaker at the moment. Cloning works fine until the in-flight engine kicks-in. I will try and work around this for now, the next thing I can try is to upgrade the CPU to a dual core. The worst case scenario here is that I abandon this approach, and mount a second monitor into the dashboard. This way I can use the Geforce screen cloning (which works flawlessly) and just cover any parts of the screen I don't need.

On the plus side, this would give me a screen for my Raspberry Pi :)

Target Locked...

Checked in with the support forum at UltraMon today, and got a couple of pointers back VERY quickly. As it happens, the application was operating exactly as expected. There's a couple of caveats with the resolutions switching, but in essence, having the primary monitor on the left causes the screen area to shift. 

I borrowed the wife's monitor this evening, set it up as a secondary monitor, told Windows it was on the left (It isn't, just in case the pics below confuse you).

It only took a short while to prove that the concept works! 

Running the mirror in a Window for testing.
When not in flight, the screen is blank as the mirrored screen area is invalid.

XWA switches to 640x480 during the start screen, and in the flight hanger, whilst running the game engine in HD means I am trying to capture an area around the (700,800)-(1300,1080) mark. This means that from the point the application is started, to the point one is in flight, the second screen is blank. As soon as the game starts, the targeting screen hits the display. PERFECT

Running the mirror in full-screen, between missions.

There's no way I could "Draw" over the Direct 3D image.
A bit of Tape helped to find the correct area.
I have the exact settings saved, but they will change when I settle on a final resolution.

The images below are taken after turning off the cockpit.This has no effect, it's just by habit.

 

In Flight, no target.

The final image below shows the main monitor (physically left) running the updated game engine at 1920x1080. The game plays with no noticable impact on performance.

The portion of screen containing the targeting computer is shown, real-time and full screen on the second monitor.

Pew! Pew!

There seems to be an issue with flickering on the target display... but only on occasion. Generally it runs as hoped. A little tweaking or extra memory should fix this.

At the moment, it seems low quality, but it's stretched to a widescreen 19" panel.

Now that I know this works as well as it does, I will be looking to get hold of a small monitor, something like a Lilliput, but it will have to be quite a bit cheaper!

Here's Where the Fun Begins...

(Amusing Note: Apparently the Blogger.com spell-check doesn't recognize the word "blog")

So far, this blog has recorded me setting up a PC, installing a couple of programs, and setting up a retro Joystick. This isn't much to get exited about. Now that I have the basics done and dusted, it's time to start branching into the more esoteric.

My aim is to make the game a little more immersive. The first idea I had is to pull some information off the screen, and put it directly in front of the user.

If you recall, in the original movie trilogy the X-Wing had a nifty little targeting system/range finder 

Which incidentally, is available as an awesome GPS App!

This was replicated reasonably well in X-Wing, but had a major overhaul in XvT and XWA.

XWA targeting display:



This shows information about the currently selected target. I want to port this to a second screen: Just for kicks at the moment, but should I succeed in my cockpit desire, I want this front and center.

Some games support multiple displays. Sadly, XWA is not one of them. It's possible to map the screen across a number of monitors, but as far as the game is concerned, there is one screen, and one screen only.

The target display is different on each craft, but is always in the same location. Sadly, this location is hard-coded in the application, and better minds than mine have been unable to alter this.

Recently, I stumbled upon the application UltraMon. This application gives one far greater control over multi-display systems. Usually this allows for a second task bar, easy screen switching etc. One of the less-used features is a partial screen clone/zoom, allowing one to clone part of ones monitor, and display it solely on a second display. This is aimed, no doubt, at the visually impaired, or those wanting to run presentations or the like.

In my last post, I mentioned I would be using the iPhone. This was to be via an application called iDisplay. iDisplay is a handy little app available in the App Store (not very expensive) that connects to an application on your desktop and turns your iOS device into a wireless, touch-screen monitor. I've used it once or twice while programming (need to leave the room but don't want to disconnect from what you're reading? Just pick up and walk... obviously I don't mean work while walking... unless you wanted to). This was going to be my second monitor while testing, not least because it's about the right size.

Sadly, this was a no-go. The iDisplay desktop application is quite resource-heavy. Even setting it lower down on the process priority list did nothing to alleviate the lag on the system. Evidertly the single core low-spec system is not up to the task.

At this point I am merely proving a concept, so I will just run with UltraMon and a second monitor for now.

Intermission!



The next thing on my to-buy list is a second monitor for my desktop PC. At the moment I only have one. I looked at the wife's monitor, and really couldn't be bothered to disconnect the various cables and paraphernalia. Instead, I connected the second port of the monitor to the PC, and I've been switching between modes to review the output.

UltraMon didn't work!

There's an option to enable/disable 3D acceleration, but it didn't make a difference. Fortunately, there's a plugin called MirrorMon that allows multiple mirroring (multiple screen sections? Interesting...) which seems to handle Direct3D a lot better:

MirrorMon running on Monitor 2 (Windowed Mode)

Full Screen, this is an exact replica of Monitor 1

The Hardware Acceleration was disabled...

Swapping the Displays resolved this.
Look at the difference!!

Output from Second Screen

At this point, Ultramon has successfully cloned a 1920x1080 Direct X display to a second monitor.
Sadly the performance on the main display isn't great, and the redraw rate on Monitor 2 is unbearable.

Changing the resolution of the second screen had an interesting result:

 It's mapped the output to the correct size, and performance is perfect, but the monitor itself is still at the same resolution as Monitor 1. This is a conundrum.

As previously noted, I will be playing in a resolution supported by the Projector, which will have an impact, but for now, I'm leaving this here.

Next Step is to connect a second monitor and see if I can get better results. Particularly, I want to map a portion of the screen to display 2, not the entire screen. This is proving very difficult with only one screen to test with.

Eye Have a Spelling Chequer...

Took me ages to figure out why I couldn't assign any shield-based commands to the WCS. Turns out the idiot that wrote the XWA template doesn't know how to spell Shield. Anyway, I've assigned commands to all 6 buttons on the WCS, and one to both RKR positions.

Buttons 1-3 are being used for targeting, namely:

Button 1 selects the nearest enemy craft that is targeting the players' ship.

Button 2 selects the nearest enemy fighter.

Button 3 selects the target currently in view.

Buttons 4/5 adjust the Shield/Laser recharge rates.

Button 6 adjusts the current shield configuration.

Technically, I can assign up to 3 commands to each button, and select the command by toggling the Rocker (RKR) button. However, this is already proving to be a paradigm shift, albeit a positive one. For now, I'm using the "UP" position on the RKR (listed above as "BTN T7") to close the crafts S-Foils, If applicable. The "Down" position is being used to enable the crafts Beam Weapon. Both of these commands are toggle-based, meaning pressing "b" once on the keyboard enables the Beam, and pressing it again disables it. Fortunately the WCS allows me to assign commands to the key-up events of every button, including the toggle positions (so returning the Rocker to the middle from the UP position registers a separate event to returning it to the middle from the DOWN position). In effect, this means throwing the switch UP closes the ships S-Foils (and turns on a red light!), returning it to normal opens them again. Likewise, setting it to Down turns on any Beam Weapons, as well as a nifty green light.

This isn't perfect of course, if one flips the switch back to the middle position while the foils are closing, the orientation is suddenly reversed, meaning you can't activate beam weapon because the foils are closed, and trying to open them puts you in an impossible position. Ah well!

I've flown a couple of test flights, and I'm happier with this layout than what I started with. I did have buttons 1-3 and 4-6 swapped, but It felt wrong. I was instinctively using my index finger to target, and kept turning my shields off!

Here ends the basic configuration of the game. Right now I have a fully working, very pretty install of XWA with a control system I need to get used to, but so far feels very slick. I'm missing the Blackhawk, and just might fire it up for a spin with the throttle one evening. 

In the meantime, I will be playing through a couple more test flights while I start to put together some very interesting ideas next. First idea involves the targeting HUD, and for now, an iPhone(!).

Briefly

Just a short post this evening. I wasn't able to upgrade the RAM on the system, as my only 1gb DDR2, NON-ECC memory module was dead. The second HDD was causing so much trouble I finally switched it out. The system now operates with two 7200 rpm 160GB drives. It's a little overkill, but with the game now running from a BIN/CUE file on the second disk, and the system having it's swap file on there as well, there's a noticeable performance increase.

I cleaned, and repaired the system chassis, as well as tidied up the internal wiring, much nicer as a box now. I intend to have it enclosed at some point, but it's nice as is for now.

Finally, I've noticed that the Talon does NOT send the ALT key from the trigger when set to Keyboard mode (i.e. the LED is ON), which means all buttons on the Talon, with the exception of the trigger (i.e. the PEW! PEW! button) operate the same on both modes. Switching to keyboard mode renders the ship incapable of firing(!)

I took the game OUT of the startup menu, it was loading too quickly, causing issues with some other Windows Services. Not a big deal,  I will hard code a shortcut key soon.

That's all for tonight!