"The latest operating systems and processors have been the main bane of Longbow 2 fans lives regarding keeping one of our favorite attack helicopter sims running."

by Guest Writer Gary "Flyboy" Wright

http://www.simhq.com/_air13/air_437a.html

As impractical as it may be, this is exactly why I maintain a legacy machine. Now if I could only find time to enjoy the "good old days".

Great article, thx a mil for doing it... this is the type of article that SimHQ becomes famous for IMO. (You won't find to many other web sites doing this.)

Excellent feature. Deserves a bookmark.

Thanks for the nice comments so far.

Can I just add that in some place the article might not make much sense and sentences or paragraphs may seem to end abruptly. This is because guod decided to edit out all references to my LB2 Windows Vista/7 Fix from my original draft of the article that I sent in.

Also I noticed an editing error:
* Where it says "Presuming you were lucky enough to decompress the 16-bit terrain files in Windows 95 / 98 / XP." - The terrain files aren't 16-bit (as far as I know of). This is meant to say that LB2 only runs on up to 32-bit systems, and that 64-bit is a no-go.

Upon reading my article here at SimHQ, what with it all set out nicely and with the screenshots - I have to say, it did bring a tear to my eye. Not for the fact that I can no longer play LB2, but for the fact that my article looks and reads so good (if I do say so myself!) that I feel like a real pro at writing (something I'd like to do professionally) and can see how far I've come since I first joined here.

Nice article, thanks for writing it.

Kind of makes me wish there was a Longbow 3. Teeheee

Regarding this line:



I'm curious if you have any suggestions on how this can be accomplished.

There are somethings you might not have taken into account. The idea behind Direct X was that it was supposed to be a standard that you could write for and you wouldn't have to worry when things were updated since they were supposed to follow the standard. When new video or sound cards would come out or new control devices they were just supposed to work, assuming they followed the standard. How are you supposed to write for a standard that changes over time?

How are you supposed to plan for an operating system that isn't going to be around for over a decade and have considerations that aren't even on the radar. All of this when, especially back then, your doing a Bataan Death March crunch just to get the game out on time and on budget? How many products didn't make it that were just worried about making a game for current systems and perhaps ones that would come out in the near term.

Also the customer wants the latest and greatest at the time so you push the envelope. This is a risk though since if the technology is still new, things may change later on "breaking" your game or causing unexpected results.

I understand your disappointment and frustration with the game becoming unplayable with the latest operating systems but the way you worded that sentence makes it sounds like these guys didn't think things through and somehow slacked off. What lesson are they supposed to have learned? Given how much has changed since then, I think the fact that people have been able to get the game to work more than a decade after it came out is a testament on how much they did right and that people think it's worth the effort even more so.

Back then I'm sure everyone would have thought there would have been number of games that would have taken Longbow 2's place. If there were then this would hardly be an issue. It's just the future didn't go in a direction people expected. Just like standards and operating systems.

Elf

One way to accomplish this is to offload as much as you can from the executable into datafiles, and use standard type datafiles such as ascii text files and standard media formats (WAV, MP3, BMP, DXT, etc.) instead of proprietary formats. Go the route of Unreal Tournament and make things easily moddable, which will let third parties extend the life of the sim well past the software developer's lifecycle. Additionally, hand off graphics (resolution, color depth, refresh, etc.) to the graphics driver so your resolution is fluid with evolving standards, not brittle with the resolutions of the day. This is even more possible today with the focus on 3D rendering (e.g. LOMAC/FC/Black Shark, JF-18) as opposed to 2D overlays (i.e. the Falcon 4, JF-15, and Longbow 2 cockpits).

GUI is also a major consideration. If you make a 3D GUI, you can more easily conform to D3D standards, but if you make a 2D GUI, make it windowable (that can be maximized with ALT-ENT) and ideally a scalable resolution. Don't get too fancy, and you don't have to worry as much about incompatibilities.

Examples that demonstrate many of these design traits are Falcon 4 (SP3 and later), and DID sims (ADF/TAW especially, though Super EF2000 also gets a nod). One of the driving design features of SP3 was to offload as much as possible from the EXE into datafiles, given that the agreement with Atari at the time had the EXE being locked as soon as SP3 finished development. However, this philosophy was also implemented in DID sims with great success. Super EF2000, ADF, and TAW will run on Windows 7 x64 systems to this day, with only minor tweaking required (though EF2000 requires a good slowdown utility). Getting into these files (once extracted), the dynamic campaign files are all ascii text that are fairly well commented, the sounds are WAV, the GUI graphics are in PCX format, and the Terrain files are essentially BMP files that rely on an external color index for different times of day.

Right now, I think Eagle Dynamics has the most flexible design engine, which has evolved from Flanker 2 to LOMAC to FC to Black Shark and back again to FC2. They also use standard file formats that are easily editable, as can be seen by the plethora of skins, cockpit enhancements, sounds, and even terrain tiles available for the entire line of ED sims.

Scott, that was your 666th post. Just thought I'd point it out. I'm not saying you're evil or anything

Moving on.

Just to chime in for the sake of being conversational, the problem with running 32bit software on 64bit operating systems doesn't relate to the bit depth of graphics, but rather memory addresses in the code (and fast short-cuts for reading and writing to it). Even recent Microsoft product has problems on a 64bit OS (I've had to deal with numerous support calls because of it).

The graphics in LB2 are formatted to fit onto a vanilla 3Dfx card, max resolution 256x256 tiles. I think that's why when you forced higher resolutions with anti-alias on the virtual cockpit broke up into 256x256 squares. Well it used to do that for me.

Just to let you know, the article has now been amended to solve the above error that I pointed out.

Scott - I see your point, but then how is it that some games ALWAYS work on newer and newer computers? The developers of these games must be doing something right, mustn't they? I think part of the problem with LB2 is that the engine is a bit tetchy (as with a lot of sim engines) due partly to all the ballistics calculations and stuff that has to be processed. With LB2 specifically, there has really always been problems regarding game performance on anything other than the recommended system or PCs out at the time of its release. Whatsmore, the engine code and files used by the game are somewhat sloppy in the fact that a lot of it was left over from LB1 and was not entirely re-written or even revised for LB2. Couple that with lots of strangely encrypted data files and even texture palettes, and there is gonna be problems.

HomeFries - you got it in one. Use standardized file types and not game-specific ones that need God knows how many third-party editors to open, edit and save.