Source ports vs. emulation

[MrFlibble]

What advantages does a source port have over playing in DOSBox?

I always appreciate all the work done with porting, but ports of VGA DOS games seem to often keep the original aspect ratio, even though the 320x200 image would be stretched to the 4:3 ratio on the actual screen. DOSBox on the other hand has this option to display screen output in the correct ratio.

[Malvineous]

Not really any advantages, just a different way of playing, and knowing that the game isn't "lost" because the working source code is still around, so you can look up how bits of it work if you want to. That and if you want to change parts of your favourite game to make a new game, it's much easier with a source port. Of course in the past ports were much more important, but now with DOSBox and other emulators, and greater CPU power to run those emulators well, there's less of an incentive from a playability point of view.

Interesting how from your perspective you prefer a game that matches the original aspect ratio of the display, whereas to me I prefer a game that is a pixel-for-pixel match to the original, with no translation layers in between that change what pixels you see.

You could consider yourself playing the game on a badly configured CRT (of which there were many back then) that had the Vsize set too small so it came out with square pixels

[MrFlibble]

Some time ago I played quite a lot of C&C Gold and Red Alert in the 640x480 resolution, which as you might know doesn't fix the aspect ratio but just places a 640x400 image neatly on the 640x480 screen. This is because the high resolution version of C&C was originally developed for Macintosh, where this kind of graphics update was pretty common. I should say that it isn't very noticeable that all graphics are a bit "squashed", especially after you have played for a while. But it's still nice if there's an option to play as close to the original intended appearance of the game as possible.

[Malvineous]

Sure it's nice, but my complaint is always how it's done. Something like double-size is easy because you just draw each pixel four times to double the height and width, and it looks fine. But when you change aspect ratio you are enlarging some pixels but not others, so it starts to look very uneven and bad unless you involve filters and different algorithms - just look at DOSBox which has a bunch, and many other emulators have even more. Then you have ones that emulate a CRT monitor in all its flickery glory - which one do you include in a Xargon port? Technically it should be the CRT emulator if you want it to look original, but then that's going to take many hours of work which IMHO is better spent elsewhere.

I tend to think that if you want the "original" experience you should use an emulator, because then whatever filters they use for aspect ratio correction/CRT emulation are available for many, many games, making it worth the effort to implement. But if you want a more modern/upgraded experience then you go for the port.

By way of example, my Xargon port was always intended to be a "vanilla" port, with no extra changes at all - just the bare minimum to make it work. The idea was that I had done the grunt work, and other people could then build on top of that to make a Xargon high resolution pack, fix some of the bugs, or whatever took their fancy.

So I guess to be clear when I say the Xargon port I did is "finished" I only mean the vanilla part is done (which is all I ever intended to do), but I don't expect it to stop there. But it'll be someone else who comes along to take the next step. Personally I'd love to see a high resolution pack for it, but if all I get is aspect ratio correction I'll be a bit disappointed, because then as you say, what benefit does that bring over playing the game through DOSBox? I'd like to see something done with it that you can't do in DOSBox.

[MrFlibble]

Technically it should be the CRT emulator if you want it to look original, but then that's going to take many hours of work which IMHO is better spent elsewhere.

I wouldn't say that the aspect correction problem is a question of emulating the "original" experience of playing a game on a CRT screen (BTW, we have discussed CRT emulation here a while ago). Rather, it is a question of properly rendering graphics.

When games were developed for low-res graphics, the assets were from the start created with non-square pixels in mind. Command & Conquer actually provides a good example of this. Here's an in-game screenshot without aspect correction (double sized):


The GDI logo on the side bar has an oval shape. However if you turn on aspect correction (or just run the game in fullscreen mode on a 4:3 monitor), the logo will be displayed as completely round:


It is also round, not oval, on the official high-resolution artwork released by Westwood Studios, suggesting that the graphics in the game were specifically made shorter vertically so that they would stretch to their intended dimensions when displayed on the screen.

It is also of note that DOS games which had both low- and high-resolution modes (like Descent II) usually match the appearance of the stretched low-res graphics in high resolution. For example, Build engine games stretch both the HUD and the rest of the screen output (e.g. monster sprites) in SVGA modes (examples here).

Similarly, Blizzard created high-resolution sprites for the Macintosh port of Warcraft with the same dimensions as the aspect-corrected DOS version graphics, not the square pixel images.

[Malvineous]

Well it depends. In this case yes, having the image appear round is probably more correct (assuming your old CRT was set up correctly - most of my early ones couldn't have the width adjusted so circles often came out squished (a bit more like a "0" than "O") so I think everyone's CRT experience is going to be a bit different. My old Trident TVGA card used to put snow on the screen when the palette was changed so Xargon used to have sprinkles all over the screen because of its palette animation - should I emulate that too??

I still think it's all very subjective. For instance I would prefer playing your first screenshot because the graphics are sharper to my eye. In the second one they look blurry to me.

You're right about Build games stretching the HUD in high resolution modes. But you probably won't be surprised to hear that I think it looks horrible and makes the high resolution modes seem like they were an afterthought In fact until now I thought it was because they had poor attention to detail and didn't realise they were stretching the HUD graphics by an uneven amount! It never occurred to me it was to keep the original aspect ratio. But likewise there are examples of other games that don't, such as Quake:



The image on the right is "320x400" (which I assume means 640x400 resolution with a 320x400 render stretched to fit). The HUD is definitely not the correct aspect. If you resize the image to be 320x400, the HUD becomes correct but the level then looks squished. So either way something has the wrong aspect ratio...

[MrFlibble]

Well it depends. In this case yes, having the image appear round is probably more correct (assuming your old CRT was set up correctly - most of my early ones couldn't have the width adjusted so circles often came out squished (a bit more like a "0" than "O") so I think everyone's CRT experience is going to be a bit different. My old Trident TVGA card used to put snow on the screen when the palette was changed so Xargon used to have sprinkles all over the screen because of its palette animation - should I emulate that too??

As I said above, I do not consider this an issue of replicating the CRT experience. There are shaders nowadays that will imitate CRT screen curvature, overscan etc., but this is completely optional IMO.

The issue of aspect correction, however, is a question of how the developers intended their art to appear on the screen. If a user's monitor had issues, the low-res GDI logo in the game and the high-res one in their artwork would be both distorted for that user. But Westwood Studios would have nothing to do with it.

I still think it's all very subjective. For instance I would prefer playing your first screenshot because the graphics are sharper to my eye. In the second one they look blurry to me.

That's because I used opengl in that shot. Here's one using overlay, does it look better to you?

(BTW, I haven't noticed before that opengl also seems to brighten/desaturate colours for some reason. Here's a screenshot for comparison with the above.)

Or you can set DOSBox to ddraw/direct3d and stretch the image to your desktop resolution in fullscreen. Then the doubled pixels will not be noticeable.

I'm not sure about Quake. A very long time ago I played it without DOSBox on a Windows system, and I configured it to run in 640x480. I think that the aspect ratio of the HUD was correct but I can't be 100% sure ATM.

However I did not claim that every DOS SVGA game does that. In fact, I was referring to how the high-res cockpit in Descent II and Decsent for Mac actually matches the aspect-corrected appearance of the low-res cockpit (GOG.com has some nice screenshots for comparison).

[DOSGuy]

I agree with MrFlibble. Many of the IBM BIOS graphics modes did not have a 4:3 aspect ratio and, thus, did not have square pixels once stretched to fill a 4:3 aspect ratio monitor, and game developers designed their games to look correct after that stretching had occurred. CRT monitors didn't have a fixed resolution but rather a dot pitch, and images looked crisp and clear regardless of resolution or stretching.

Then we got to the world of LCD screens that have a fixed number of square pixels. If you display any resolution other than the monitor's native resolution, you'll usually end up in a situation where you're using 0.8 or 1.2 physical pixels per pixel, which makes the image blurry. For that reason, I try to set games to use a resolution that is some whole multiple of their native resolution (i.e. display a 640x480 game as 1280x960) and leave black bars around the leftover space on the monitor in full screen mode, but that doesn't address the issue of aspect ratio correction. There doesn't seem to be a great solution to that problem: monitors with square pixels just can't display a clear image when they display rectangular pixels. You may have noticed that the thumbnails on this site are set to 160x120 so that they're forced into a 4:3 aspect ratio and appear as they were intended to look, but I don't apply any aspect ratio correction to the full-size image when you expand a thumbnail; a Mode 12 screenshot will appear as 640x400, I make no attempt to stretch the image to 640x480 to correct the image, so things that are intended to look like squares become rectangular and things that are intended to look like circles become ovals. Maybe I should enforce aspect ratio correction on expanded screenshots, but I've prioritized presenting an image that shows each pixel clearly over getting each pixel to have the right dimensions.

I don't use DOSBox's aspect ratio correction when gaming because it really slowed down the emulation when I first tried it a decade ago, and I haven't cared enough to revisit the issue since. I still have some hope that some new type of monitor will come along and do away with native resolutions again. There had been a sort of "flat CRT" technology that used a mirror to direct a laser at the phosphors on the screen, which you couldn't do with a stream of electrons, but the technology never caught on.

[MrFlibble]

I don't use DOSBox's aspect ratio correction when gaming because it really slowed down the emulation when I first tried it a decade ago, and I haven't cared enough to revisit the issue since.

The aspect correction option is only really necessary if you have a widescreen monitor, want to play in windowed mode or set DOSBox to a certain fixed fullscreen mode resolution higher than the original. On a 4:3 monitor, fullscreen with fullresolution=original should produce the intended image (turning aspect correction on in this case will just make everything blurry).

It is my understanding that the rendering speed with aspect=true depends on the output method. In fact, I think it does not work at all with output=surface, and performance may vary with opengl and ddraw depending on the system.

[Malvineous]

I'm looking forward to when UltraHD and other high-DPI monitors become cheap and mainstream. Already with those the dot pitch is finer than with a CRT screen, and there is talk of doing away with anti-aliasing since the pixels will be so small you won't need it. Once that happens then there will be no visible unevenness when doing aspect ratio correction.

But it's all just a personal preference. As DOSGuy says, his screenshots prioritise showing each pixel clearly, and that's what I prefer also. I like to see things 1:1 with no meddling by software. Perhaps this is just my background as a programmer, wanting to see exactly what the hardware is doing. If there are filters running not only can it disguise problems but you can't be sure whether a graphical glitch is with your code or a bug in the filter. Or you go take a screenshot to get a closer look at what the graphics code is doing and suddenly your 16-colour game has more than 256-colours in it and you can't easily tell which pixel is which. I mean sure you can turn the filter off, but then someone in my position would never end up turning it on in the first place. So I guess that's why it seems so unimportant to me - I would rarely use it as it would hinder me more often than it would help. But sure, that's just my unique situation, I don't expect everyone else to be the same.

So I'm not trying to say there's anything wrong with aspect ratio correction at all. I guess I am considered a heretic when I admit to running DOSBox full-screen on a 16:10 monitor with aspect ratio correction off, precisely so that a 320x200 image fills the whole widescreen monitor. But hey, 320x200 with square pixels is 16:10

And for the record yes I still find the updated screenshot blurry. It's only very slight of course, but it's enough to make me think something is not right. When I see a game like that on my own machine a bunch of things go through my mind with barely a thought - did I misconfigure my screen resolution? Has a bug been introduced in the last update of my video card drivers? Is the video overlay surface size off by a couple of pixels due to a bug? And so on. Again this is unique to my situation, but it causes me less panic if I switch any filters off and just stick with 1:1 pixels! Even if it's not technically the way the image was meant to be seen.

[MrFlibble]

And for the record yes I still find the updated screenshot blurry. It's only very slight of course, but it's enough to make me think something is not right. When I see a game like that on my own machine a bunch of things go through my mind with barely a thought - did I misconfigure my screen resolution? Has a bug been introduced in the last update of my video card drivers? Is the video overlay surface size off by a couple of pixels due to a bug? And so on. Again this is unique to my situation, but it causes me less panic if I switch any filters off and just stick with 1:1 pixels! Even if it's not technically the way the image was meant to be seen.

Thanks for the feedback! I think I more or less got your point.

For a while I did not pay attention to the aspect correction issue myself, and would switch between windowed DOSBox mode without aspect correction and fullscreen mode (on a 4:3 monitor) without even noticing that the image was actually different.

The game that made me think about this is C&C95. I just couldn't decide which resolution was the intended way to play the game: 640x400 stretched to 4:3, or 640x480 which still displayed a 640x400 image centred on the screen. The problem with this edition of C&C is that originally it was a Macintosh port, and the high-res interface was designed for the 640x480 resolution. When using the 640x400 mode on the PC the interface graphics would appear overstretched, which was quite noticeable with the faction logos.

[Malvineous]

I think official ports can often complicate matters. One that comes to mind (unrelated to aspect ratios) is Rockford. It's a 16-colour EGA came that came from some other platform, but the graphics were taken across to the PC unchanged. But weirdly, the game changes the EGA palette to make some colours appear identical, reducing the total number of colours displayed from 16 to around 14. So you are in the odd situation where the hardware can display 16 different colours, you're drawing an image on the screen that contains 16 colours, but then you are changing the palette so that only 14 different colours are shown!

It surprised me when I first exported the graphics and noticed that the colours were all wrong, but loading the correct palette removed some detail from the image in the process of making the colours look correct again.

So that case also makes you wonder whether the original platform was more correct or not.

To give another more on-topic example, the Xargon music has velocity values for each note event in the background music. The CMF player used in the original game ignored these, playing every note at full velocity and giving the "official" music a particular sound. But if you write a source port, you are free to take advantage of this unused song information and if you do, a couple of the Xargon songs sound different. Certain repeated notes actually fade out a bit like an echo which they don't in the original game.

In cases like this I'm always torn between reproducing the original game unchanged, and taking advantage of new content that was in the original game but never used. The argument works both ways - do you match the original game, or do you match what the composer originally intended when supplying the files to the game developer?

[MrFlibble]

To give another more on-topic example, the Xargon music has velocity values for each note event in the background music. The CMF player used in the original game ignored these, playing every note at full velocity and giving the "official" music a particular sound. But if you write a source port, you are free to take advantage of this unused song information and if you do, a couple of the Xargon songs sound different. Certain repeated notes actually fade out a bit like an echo which they don't in the original game.

In cases like this I'm always torn between reproducing the original game unchanged, and taking advantage of new content that was in the original game but never used. The argument works both ways - do you match the original game, or do you match what the composer originally intended when supplying the files to the game developer?

That's a fact I didn't really know - I think you posted something about it a while ago but I didn't pay attention back then?

Anyway, you're right that source ports (and engine recreations which are based on reverse-engineering like OpenDUNE) allow to discover and fix bugs, errors or intended features which got lost somewhere during development. As for the question whether a port should keep true to the original game or fix the errors, I guess it would be nice if the user were made aware of the difference and allowed to choose between the possible options.

In fact, if in my initial posts I made an impression of someone who's strictly pro-original and does not like ports, I have to say that this is not the case. I certainly like the idea of giving the player a choice between the original game and a port. And within ports, it is possible to implement optional features so that users can decide for themselves what they would like, and switch between the different modes at will.

I should also say that my interest in this topic was in part influenced by a thread made in the Duke4.net forums that is called Is there any reason NOT to use a source port in this day and age?

To me, the original DOS versions have a certain nostalgic value. Also some port authors seem to get carried away with adding many new features which might be great things and real fun, but they're not part of the original experience.

[Malvineous]

Yes I agree with that. Once a source port advances beyond a certain point, it gets a different feel to the original. Which is fine for entertainment, but not so good for nostalgia. But that's why I have always felt that a source port is meant for keeping a game current, where an emulator is for nostalgia.

Of course in recent years that line has blurred somewhat, as DOSBox and CPU power has gotten to the point now where a vanilla source port and emulation can look the same, perform at the same speed, and be just as easy/difficult to load and start playing. So where in the past the Duke3D source port was important because it was the only way you could play the game at a high framerate on a modern PC, today it works fine in DOSBox so it's not so crucial. But even so, the programmer in me likes to see source ports because then you know the full source code for the game has been preserved in a working state. And from a preservation standpoint, you don't know whether the code is fully functional or not until someone tries to port it, or at the very least compile it. So even with DOSBox, I still like to see source ports of games.

Also, the process of porting means you look very closely at the game's source code, which can be quite interesting in and of itself. It was because of what I found while I was porting Xargon that led me to discover the hidden Jill of the Jungle level editor, after all! Other things like cheat codes and debug keys also tend to be discovered in the process, so sometimes it can be worthwhile just for that.

[Calvero]

Also, the process of porting means you look very closely at the game's source code, which can be quite interesting in and of itself. It was because of what I found while I was porting Xargon that led me to discover the hidden Jill of the Jungle level editor, after all! Other things like cheat codes and debug keys also tend to be discovered in the process, so sometimes it can be worthwhile just for that.

The cheats for the DOS version of Double Dragon II where also found by looking at the source code.
The source code was recovered by undeleting a LHZ archive file that was on one of the game disks.