Star Wars Tie Fighter (1995) Tweak Guide

This is a Tweak Guide video for Star Wars: Tie Fighter Collector's CD from 1995. I will be covering the following:

- Fullscreen resolution
- Window resolution
- Output modes
- Scaler
- Aspect ratio for correct 4:3 image
- CPU cycles to avoid turrets not firing issue
- Sample rate for better quality Sound Blaster
- Configuring a MIDI Synth
- Soundfonts
- Changing the game to output General MIDI
- Joystick tweaks for hat and throttle
- DOSBox key mapper
- Using the GOG files to create an installation CD
- Installing and playing the game with the created installation CD

Link for VirtualMIDISynth: http://coolsoft.altervista.org/en/virtualmidisynth

Link to Soundfonts: http://coolsoft.altervista.org/en/virtualmidisynth#soundfonts

Am I the only one who prefers the non-true aspect ratio? Using DDraw, the pixels look completely square and sharp, and the game fills more of the screen. Also, I hate the 640x480 combat resolution. In my opinion, this game looks so much better consistently pixelated. :)

I can relate to preferring the 320 x 200 graphics, but the wrong aspect ratio? Everything is stretched horizontally. This means that round shapes are now oval and that you move faster left and right than you do up and down.

The pixels back in the day were non-square, hence the issue with scaling. There is one resolution that does both: square pixels and correct aspect ratio: 1600 x 1200. So if you have a 1920 x 1200 screen, you're good to go.

Actually, in testing different resolutions today, I realize I WAS referring to the correct 4:3 aspect ratio, but that for some reason, I am able to get it without messing with the screen resolution settings in the config file.

On my machine (a notebook with an integrated Intel card), if I keep the fullscreen resolution setting totally blank in the config file, and keep the aspect ratio set to false, and have it set in DDraw mode, the aspect ratio is a perfect 4:3. If I follow your guide and set the fullscreen resolution to my native 1366x768 and change the aspect ratio to "true," it makes the image perfectly square (1x1), which means the pixels are too narrow vertically.

In any case, yes, it definitely looks better in true 4:3. I have the same issue with running the Lucasarts adventure games in ScummVM--if I have ScummVM's aspect ratio fix selected in the graphics options, it messes the image up by making it perfectly square, but if I uncheck that box, it displays a correct 4:3 ratio.

I'm wondering if maybe there's an automatic aspect ratio correction setting in my video card setup options that I don't realize I have turned on, and so Dosbox is correcting an already correct 4:3 aspect ratio by narrowing it horizontally (giving me the square image.) I must investigate this. :)

Ah, I know what you mean!

The image gets scaled from 320 x 200 to whatever resolution the monitor has. Now scaling can be done, by the application (DSOBox), by the graphics card (Nvidia, AMD, Intel all have options for this, or by the monitor (Benq for example has terrific options).

If you graphics driver is set to aspect ratio scaling, the end result will be similar.

Who does the best job? That's hard to say. I haven't looked at comparing DOSBox vs. graphics card scaler, I doubt there is much difference. Personally I have set my scaling options in my Nvidia driver to not scale or 1:1 pixel mapped, because this allows me to "see" what resolution is really being used if that makes sense.

I might do a video explaining all of this with examples because it can quickly become confusing.

It could be that the graphics driver scaling options interfere with that from DOSBox. With Intel cards, you right click on the blue icon on the bottom right > Graphic Properties. Here look for scaling options.

I need to correct this misinformation. You do NOT move faster in the direction pixels are stretched (replicated as per scaling algorithms). It does not in any way impact game physics nor input. All it does is, as above, replicate pixels in whatever dimension the image is stretched. Thanks. That is all. /end

This is technically true. But when the pixels are not scaled properly, it can APPEAR that one is moving faster on one axis versus the other. The "correct" display (at 320x200 resolution) has non-square pixels, displayed in a 4:3 aspect ratio. So when one moves up or down, they move a certain number of pixels per second. But when moving side to side, they actually move a SMALLER number of pixels per second, because there are fewer pixels per inch horizontally than there are vertically. This is by design; now the player moves at the same speed in real distance (i.e. in inches on the screen) both vertically and horizontally.

When the aspect correction is not working, the game displays using square pixels, in a 16:10 aspect ratio. Now the screen is wider than it used to be. The movement speeds are the same in terms of pixels per second. But they are no longer the same in terms of inches of screen per second. Left-right motion now moves more distance on the screen per second than up-down motion.

Nothing changed in the game itself. It's still responding to controls and inputs in exactly the same way. But since the display is stretched horizontally, it makes horizontal motion LOOK faster. This can make playing the game feel weird.

The game also renders in 640x480 which DOES have square pixels. That exact ratio of 1:1.33 (4/3) is why Mode X was a big deal back in the early post-SVGA days. However, what the game is doing internally is taking into account the aspect ratio for the pixels and scaling accordingly. I"ve done this myself in software-rendered 3D engines I've written where it had to deal with multiple resolutions [0].

It may appear to move more quickly, but I even debate this point a bit. It's not altering the viewcone or FOV, which is what I think the confusion stems from. DOS games generally didn't allow the enduser to mess with that. That's more of a modern 3D consideration. My own engine did, because I really wasn't sure what the ideal FOV should be, but that's another matter (technically all viewcone/FOV modification does is alter the view distance to the draw plane. The FOV can be calculated from that or vice-versa with a bit of Trig [1]).

I think it really comes down to whether a horizontally stretched display bothers you. For me it doesn't, but for some it might.

[0] Code from my engine. Note aspect only needs to be taken into account on 1 dimension :
Result = ( (-The_Y * Vertical_View_Distance * Aspect_Ratio) / The_Z) + Half_Screen_Height;

[1] Code from my engine for handling this : Temp_View_Dis = Draw.Get_Half_Screen_Width () / Trig_Tables.Tan ( (Horizontal_FOV / 2) * Trig_Tables.Precision );

This is interesting. But wouldn't the game always assume the display was 4:3? I would expect that when running in 640x480, the game assumes square pixels, but when running in 320x200 it assumes non-square pixels. Since DOSBox can now run the game in 320x200 with square pixels, this can mess up the horizontal display width and can therefore make horizontal motion appear to be slightly faster than vertical motion. But maybe I am wrong about this; maybe the game is smart enough to actually know whether the pixels are truly being displayed as square or not? I would be surprised, since nearly every display was 4:3 at the time, but maybe this is the case. I don't see what the FOV has to do with it. The issue is that the pixels are being stretched horizontally. The viewable area is the same, but it's being displayed wider than it should be, so the horizontal axis is longer than it should be. So one distance unit in the horizontal direction is displayed as longer than the same distance unit in the vertical direction. Unless, as stated above, the game actually recognizes the actual pixel shape and compensates accordingly. But I doubt this is the case.

Honestly the same behavior can happen in a modern game, if one tries running it at a 4:3 resolution but then displays that stretched to fit a widescreen monitor. A first-person shooter played like this would not only have a distorted image, but the mouse would seem a little more sensitive horizontally than vertically, because the horizontal distance (and therefore horizontal motion) has been artificially stretched and lengthened. I agree that this is the more important point. I dislike the stretched image because circular things become ovals (planets in the background, for example) and this looks really off to me. So I always prefer to set the game to run in 4:3 no matter what the resolution is. But if others aren't bothered by the stretched image then there's no problem. Any perceived differences in movement speed are probably really small.

A few basics need to be understood. The game is rendered at a fixed resolution. Be it 320 x 200, or 640 x 480. The game, unlike modern games, does not natively support any other widescreen resolutions.

I'll give you an example that will show you what's going on.

Let's say you play tie fighter at 640 x 480 on a CRT monitor. CRT monitors had controls to adjust the vertical and horizontal height. Now let's say the user adjust the image so that it fits the entire width of the screen, but the image is only 1 inch in height. Basically a horizontal bar.

Do you still think that when you move the joystick, that the ship on the screen moves at the same speed in all directions?

From the game perspective, it still moves at the same amount of pixels per time. However, 200 horizontal pixels might measure 5 inches, but 200 vertical pixels might only measure 1 inch.

So in this case, the ship might move 200 pixels in both, horizontal and vertical, but, on the screen, it will move 5 times the distance horizontally.

Hope this clears up what my point was.

In essence the law of speed on screen= distance on screen / joystick movement time is against your argument.

It's like saying, two people who walk 1 pace per second, but one does longer paces, are going to walk at the same speed.

How does this affect gameplay?

Well let's say you're flying straight. There is enemy 300 pixels to the right, and another one 300 pixels up. So from the game perspective, they are the same distance from the cross hair. And if it takes 1 second of full joystick movement to travel 300 pixels, then yes, you would be able to target the top ship in the same time as the ship on the right.

However because, on the actual screen, the top ship is much closer and the ship on the right side is much further away, your hand-eye coordination will be off and you will over- or under shoot. Now over time you will likely get used to this and you brain will compensate, but when you then play a game that's got native widescreen support, you will have issues again.

So to sum it up: Use aspect=true :)

No, it is most certainly NOT. You attempt to argue this point because, very clearly, you have no idea of how games function on a programming level. It's all appearance. The timing remains the same. This inches to pixels argument does not function on an operational level. All it is is a scaling ratio in screen-space. Look up image-scaling algorithms. Point invalidated.

If you want that for a more accurate rendering interpretation of the game, so-be-it. Then definitely use this. But to ascribe the ridiculous notions you're attempting to correlate with operational functionality of the game, interpreter (DOSBox in this case), or engine is nothing short of willful ignorance.

Personally, I couldn't care less what yourself or anyone else's preference is on whether the screen is scaled horizontally. That's a personal choice and people should use whatever they prefer. But I take umbrage with people saying things that are patently FALSE simply because they're attempting to appear more knowledgeable than they actually are or because they aren't willing to actually inform themselves properly.

I really am having trouble understanding your argument. Neither of us is claiming anything about the game engine; that's independent of the screen. In fact, that's the source of the problem. The game outputs a certain number of pixels; if the screen stretches those horizontally, then objects in the game will appear to move faster horizontally than vertically. How could that not be the case?

TL;DR : The horizontal stretching issue only creates a perception problem, not an actual problem. At best it could be likened to an optical illusion.

Edit :
Reading your above reply.... I don't even honestly know where to begin. I think you already understand the issue, however the OP is misrepresenting the problem. FOV issues CAN affect turning speed (this is part of the reason Rockstar clamped down on FOV mods for GTA 5 as it could be used as a form of cheating). His argument seems to conflate the two issues : Actual turning speed with perceptual turning speed.

So, yes, mathematically, FOV has a profound impact on the game engine and feel, but not the way he's attempting to explain it, and that's before I even extricate what he IS explaining with this concept. This is why I listed the math behind it from my own implementation of a working 3D engine (looking at these images will help illustrate the problem, notably this one.

On the note of the game recognizing pixel aspect ratio : The game can render at a given resolution and know what the pixel "shape" will be, but it has no means of knowing how an interpreter (DOSBox) is rendering the end pixels on the screen at whatever scaling ratio. So, in essence, you understand and are correct on this.

It's just appearance?

Well what do you look at to actually play the game? As it APPEARS on the screen! *Face palm*

Nobody gives a hoot about "programming level". You're just clutching for straws because you got caught out on not knowing what you're talking about.

You can play your games rendered at 3 x 2 pixels resolutions and marvel at the fact that on a "programming level" there is no problem. The fact that you can't see anything on the screen escapes your narrow mind...

Agree.