OpenFodder - Cannon Fodder opensource

[drnovice]

Quote

"War had never been so much fun"

Cannon Fodder is returned! Old fans can go back to dream again for a while...

It's released OpenFodder by Segra!

He worked to create by reverse engineering this famous game, and the result is a porting on C++ crossplatform and in both Amiga/DOS of its versions.

The port includes even bonus stuff as Amiga Format Xmas Special and Plus Packet (with a nice Quiz).

Last release (OpenFodder 0.9) is a beta, any bugs will be fixed ASAP.

The GIT Project:

https://github.com/segrax/openfodder

and the Releases (currently 0.9):

https://github.com/segrax/openfodder/releases

Here a review of the porting:

http://www.indieretronews.com/2015/10/open-fodder-open-sourced-cannon-fodder.html

Soon many other news!

[MrFlibble]

Nice!

[segra]

hey thats pretty cool :)

[MrFlibble]

hey thats pretty cool :)

Now I'm confused. Aren't you the developer?

[segra]

Now I'm confused. Aren't you the developer?

Yeah, I just couldn't help myself though ;)

[MrFlibble]

OK, I did not really have the time to check this as I have never played the game and don't own it. First things first, Cannon Fodder and it's sequel is currently sold by GOG.com:
https://www.gog.com/game/cannon_fodder
https://www.gog.com/game/cannon_fodder_2

However, there is a demo/shareware version, originally distributed by MVP software: 1cf2.zip. According to the readme, the shareware version contains 20 levels, compared to 72 in the final game (a pretty generous offering for a shareware game I should say!) There's also a demo of Cannon Fodder 2 as well: canfod2.zip, which was apparently initially distributed on a coverdisk but made its way to a game demo downloads site. I hope that these versions are supported by the port alongside the registered releases. (If not, please add such support if possible.) A quick Google search suggests that there are Amiga demo verisons as well, but I know nothing about it.

I first downloaded the 32-bit version (in a hope that it would be more stable), but it refused to work on a 64-bit system, citing a missing MSVCR120.dll. As it turns out, the 64-bit version wants the same file too. The relevant help page at Microsoft is not available anymore.

I noticed that the zip contains a lot of files in the WAV format, apparently extracted from the Amiga version (?). There's no explanation of what they're doing there. I should note that usually source ports/engine recreation projects do not bundle any game data with the engine but offer it as a separate download, especially if the game is still proprietary. The main reason for this as I understand it is that if you bundle everything in one archive and then release it under the GPL license for example (as you did), it is supposed that the license applies to all contents of the archive, which is not true for game data. This has been confirmed to be incorrect.

The same thing is with the special Amiga coverdisk version. There isn't any apparent license file provided for this version (in fact there doesn't seem to be any license file at all in the archive), and I'm completely unsure if that version is/was allowed for free distribution. For the reasons specified above, I would suggest at least moving the data files to a separate archive.

On 17.03.2016 at 1:06 PM, drnovice said:

Many DOS games have aspect ratio 1,6:1 (starting by 320x200 pixels size), so if you want maintain this ratio and put it into a modern screen like 16:9 (standard going from 4:3 to 16:9, by the advent of multimedia movie formats) the result is pillarbox (black borders on left/right margins).

Instead if you try to put same dos games ratio (1,6:1) into 4:3 screen, result is letterbox (black borders on top/bottom margins).

The correct aspect ratio of DOS VGA games isn't 16:10, but 4:3. Here's an article with a detailed explanation. For example, the DOS version looks like this in DOSBox with aspect correction turned on:

From you reply it seems that OpenFodder does not support correction of the DOS version to 4:3 at this point, although I would await for a reply from segra for a definite answer.

[segra]

6 hours ago, MrFlibble said:

OK, I did not really have the time to check this as I have never played the game and don't own it. First things first, Cannon Fodder and it's sequel is currently sold by GOG.com:
https://www.gog.com/game/cannon_fodder
https://www.gog.com/game/cannon_fodder_2

However, there is a demo/shareware version, originally distributed by MVP software: 1cf2.zip. According to the readme, the shareware version contains 20 levels, compared to 72 in the final game (a pretty generous offering for a shareware game I should say!) There's also a demo of Cannon Fodder 2 as well: canfod2.zip, which was apparently initially distributed on a coverdisk but made its way to a game demo downloads site. I hope that these versions are supported by the port alongside the registered releases. (If not, please add such support if possible.) A quick Google search suggests that there are Amiga demo verisons as well, but I know nothing about it.

I first downloaded the 32-bit version (in a hope that it would be more stable), but it refused to work on a 64-bit system, citing a missing MSVCR120.dll. As it turns out, the 64-bit version wants the same file too. The relevant help page at Microsoft is not available anymore.

I noticed that the zip contains a lot of files in the WAV format, apparently extracted from the Amiga version (?). There's no explanation of what they're doing there. I should note that usually source ports/engine recreation projects do not bundle any game data with the engine but offer it as a separate download, especially if the game is still proprietary. The main reason for this as I understand it is that if you bundle everything in one archive and then release it under the GPL license for example (as you did), it is supposed that the license applies to all contents of the archive, which is not true for game data.

The same thing is with the special Amiga coverdisk version. There isn't any apparent license file provided for this version (in fact there doesn't seem to be any license file at all in the archive), and I'm completely unsure if that version is/was allowed for free distribution. For the reasons specified above, I would suggest at least moving the data files to a separate archive.

The correct aspect ratio of DOS VGA games isn't 16:10, but 4:3. Here's an article with a detailed explanation. For example, the DOS version looks like this in DOSBox with aspect correction turned on:

From you reply it seems that OpenFodder does not support correction of the DOS version to 4:3 at this point, although I would await for a reply from segra for a definite answer.

Yeah, There is a link to GOG in the Readme for obtaining the Retail data,

 

That demo works fine, it will give you an MD5 warning, but it will still work (Just put it in the Dos_CD directory). Cannon Fodder 2 isn't really supported, but it will start up (it contains a number of sprites which are not handled, sound effects, and some of the mission data is missing)

Its also worth mentioning, the data included with that CF1 Demo... is actually the full Retail data (The 'Game Won' image has been changed, apart from that its 100% identical),  they simply modified the mission table in the executable.

You're missing the visual studio 2013 run-time, x86 and x64 versions are available from here: https://www.microsoft.com/en-us/download/details.aspx?id=40784

Yeah, the WAVs are extracted from the Amiga version - as this version hasn't been available for purchase for 20 years now, they should be in a separate archive... however because of their inclusion, i never bothered to implement the DOS music player... in my opinion, the music with the DOS version sucks, after I moved from the Amiga to Dos.. back when I was about 9, i spent hours trying to figure out why the voice track on the intro didn't work :)

We've been working on the assumption the 'Amiga Format Special' was given out as a free demo of the game (I couldn't track down any copyright notices, or anything at all about it.. even after reading through the Amiga Format magazine it was included on), so we figured, why not, its two missions, hard to track down, and not available since the December 1993 magazine came out, its also difficult to extract from the Amiga disks.

 

Open Fodder is running in multiples of the original resolution (320x200 - all the graphics are built to this resolution), with the built in SDL2 feature to stretch the image to the window size... if you start it up, and press the '-' key, the resolution will decrease.. all the way to 320x200, pressing '+' will increase it in multiples of 320x200 (assuming you're using the DOS version... the Amiga version uses the Amiga resolution) - until it hits full screen resolution.

Playing in DosBox with aspect=true, appears to make the images stretched,

Open Fodder in this screenshot is running in a window 640x400, DosBox was set to start in 640x400 with aspect=true...  (however it appears to be closer to 533x400)

The 'Load' / 'Save' text is very blurred

 

Edited March 19, 2016 by segra

[drnovice]

MrFlibble, that article made me laugh: native aspect ratio was 320x200, then stretched it to put resolution on OLD monitors.

All DOS Game porting (SCUMMVM, Dune2, EOB, etc) starting to work on 320x200, even DoxBox by default has aspect=false, because it was a manipulation of original format (stretching).

[MrFlibble]

16 hours ago, segra said:

That demo works fine, it will give you an MD5 warning, but it will still work (Just put it in the Dos_CD directory). Cannon Fodder 2 isn't really supported, but it will start up (it contains a number of sprites which are not handled, sound effects, and some of the mission data is missing)

Its also worth mentioning, the data included with that CF1 Demo... is actually the full Retail data (The 'Game Won' image has been changed, apart from that its 100% identical),  they simply modified the mission table in the executable.

I haven't been able to check the port out with the Visual Studio libraries yet, I expect the port to implement the shareware version limitations when it detects this version, right?

16 hours ago, segra said:

Playing in DosBox with aspect=true, appears to make the images stretched

Exactly, this is what this function is supposed to do: stretch the 320x200 image vertically to 4:3 ratio:

Quote

 

aspect = true | false

Do aspect correction. It only affects non-square pixel modes like VGA Mode 13h, which has a resolution of 320x200 pixels and is used by many DOS games (DOOM, etc). Recommended as such games were designed for 4:3 displays, and without aspect correction will look distorted and not as the developer intended. [source]

 

This means that DOS VGA output will be stretched at least to 640x480, but of course larger resolutions are possible depending on the host system's actual screen.

16 hours ago, segra said:

Open Fodder in this screenshot is running in a window 640x400, DosBox was set to start in 640x400 with aspect=true...  (however it appears to be closer to 533x400)

The 'Load' / 'Save' text is very blurred

I'm not sure why you locked the DOSBox window size to 640x400, but this is the cause of the extensive blur shown on the screenshot: DOSBox tries to compensate for the inability of LCD screens to draw non-square pixels by means of interpolation (cf the article I linked to above), which gets excessive at resolution this small. If you set windowresolution=original, you should get this instead:

If the article I linked to in my previous post was not convincing enough that 4:3 is the proper aspect ratio for DOS VGA games, here's a few more sources (VOGONS hosts the official DOSBox developers' forums):
http://www.vogonswiki.com/index.php/General_monitor_advices
http://www.vogons.org/viewtopic.php?t=35029
http://www.vogons.org/viewtopic.php?t=17110
http://www.vogons.org/viewtopic.php?t=29452
http://www.vogons.org/viewtopic.php?t=28500#p226562
http://www.vogons.org/viewtopic.php?f=31&t=37974#p338232

Of course it can be argued whether the developers intended the image to appear stretched, but there is no doubt that this is how the game looked for DOS players back in the 90s. So it would be very nice if you added the option to stretch the image (in the same manner as DOSBox does it or otherwise) to the port.

BTW, did you reverse-engineer the Amiga version as well, or just added support for that version's data files? I'm curious what the Amiga resolution was but so far I have found no conclusive information on this.

[segra]

12 hours ago, MrFlibble said:

I haven't been able to check the port out with the Visual Studio libraries yet, I expect the port to implement the shareware version limitations when it detects this version, right?

Thats what should happen, but at the time of release, I hadn't seen that particular version (which is why it gives an MD5 error).

I only spent ~4 months (while working a full time job) doing this entire port, so as you can guess, most of the time was spent coding and bug fixing, not hunting for demos :)

 

12 hours ago, MrFlibble said:

Exactly, this is what this function is supposed to do: stretch the 320x200 image vertically to 4:3 ratio:

 

This means that DOS VGA output will be stretched at least to 640x480, but of course larger resolutions are possible depending on the host system's actual screen.

I'm not sure why you locked the DOSBox window size to 640x400, but this is the cause of the extensive blur shown on the screenshot: DOSBox tries to compensate for the inability of LCD screens to draw non-square pixels by means of interpolation (cf the article I linked to above), which gets excessive at resolution this small. If you set windowresolution=original, you should get this instead:
 

All my ratios/resolutions are based on the original images in the data, thus, to me, a 2x-scale should be 640x400 (as all images in the DOS version are 320x200), thats why I told dosbox to cap the size to that resolution.

 

12 hours ago, MrFlibble said:

If the article I linked to in my previous post was not convincing enough that 4:3 is the proper aspect ratio for DOS VGA games, here's a few more sources (VOGONS hosts the official DOSBox developers' forums):
http://www.vogonswiki.com/index.php/General_monitor_advices
http://www.vogons.org/viewtopic.php?t=35029
http://www.vogons.org/viewtopic.php?t=17110
http://www.vogons.org/viewtopic.php?t=29452
http://www.vogons.org/viewtopic.php?t=28500#p226562
http://www.vogons.org/viewtopic.php?f=31&t=37974#p338232

Of course it can be argued whether the developers intended the image to appear stretched, but there is no doubt that this is how the game looked for DOS players back in the 90s. So it would be very nice if you added the option to stretch the image (in the same manner as DOSBox does it or otherwise) to the port.

320x200 is considered a 4:3 ratio with 'non-square pixels' ( and it really depends on your particular screen/tv as to how many vertical lines you have )... https://en.wikipedia.org/wiki/Computer_display_standard

The reason it was decided to use the original image sizes as the base for the scaling, was simply because I ran into issues on various screens I tested on... originally a scale had been chosen which stretched the image, however the blurring becomes really terrible on a resolution of 2560x1440  (my monitor native res)... using the original image scale, it still looks clean

While it probably would be nice for some users to be able to apply the original "blur" look, my work on Open Fodder is done (except for fixing any bugs which appear), i have no plans on adding anymore features or adding support for Cannon Fodder 2.

The original goal was to get the DOS version running and fully complete-able, when it had about 20 sprites left to implement, hungover one Saturday morning, I made the call to add support for the 'Amiga Format Special Edition'... as it was fun when I was a kid, that then lead to adding full support for Amiga data, and Cannon Fodder Plus (which probably added about 2-3 weeks work onto the project in total)

 

12 hours ago, MrFlibble said:

BTW, did you reverse-engineer the Amiga version as well, or just added support for that version's data files? I'm curious what the Amiga resolution was but so far I have found no conclusive information on this.

Partially, The disassembly of the DOS and Amiga version (including both Amiga Demos) is very similar, in most cases, you can compare the disassembly side by side - the exceptions being the graphics/sound routines... Most of that work was done just to add support for the Demos, thankfully the maps/collision data themselves on the PC version, are direct copies of the Amiga version (this can be seen in the original dos engine, which does an endian flip when it loads them)

While I'm still not entirely sure, I do believe the game was written in assembly, a number of items found throughout the disassembly gave me this impression - such as jumps from the middle of a function into another function... the use of global variables for everything instead of using the stack to push parameters to functions (in some cases, the contents of the global vars are pushed to the stack prior to a function call, the called function then clobbers those variables, and on return, the variables are restored... and in at least 2 instances, this was done before a Loop (all this is changed in Open Fodder, function parameters are now used )

There was also large amounts of game logic, which was laid out in such a way, that it clearly wasn't basic if/else statements (of course, they could of simply been using a large amount of GOTOs in these locations.. but unless the original code is released, or one of the devs speaks up,  we will never know)

 

The static images are mostly 320x260 in the Amiga version (but some are smaller), it does top/bottom/left/right 'Letter boxing' on practically all other screens (you'll notice in OF, the Amiga version only has the black border at the bottom on the recruitment screen), whereas the original had it on all 4 sides. numerous hours where spent weighing up the cons/pros of the various possible outcomes, and a 'middle ground' was selected, to prevent constant changing of the game window resolution.

The 'middle ground', is the in-game resolution of 320x225 (I'm not sure why this is, 225 and not 224... as 0x0F tiles * 16 pixels height = 224, not 225)... is used as the multiplier basis of the window height, and all images are shrunk from 320x260 to 320x225. Thankfully, this has no noticeable effect... as this entire ordeal was a massive pain, which considerable time was spent trying to rectify... generally to find that one 'edge' case, which didn't work properly.

This also led to the discovery that the original game suffered from this bizarre setup... as the mouse is restricted from going below about the 230 pixel mark.. even on screens where buttons exist to the 240-250 mark... this is most noticeable on the Amiga Format Special 'level selection' screen, and the Cannon Fodder Plus Quiz screen, as you cant go all the way to the bottom of the buttons

 

Rob

 

[MrFlibble]

On 20.03.2016 at 7:38 AM, segra said:

While it probably would be nice for some users to be able to apply the original "blur" look

It should be noted that the blur is certainly not part of the "original look" - the non-square pixels were pretty sharp on 4:3 CRT screens unless their tuning was messed with. The blur is an inevitable side-effect of LCD screens being incapable of drawing non-square pixels.

I should say it's a pity that you're not going to update the project further. Perhaps add a minor fix to get the demo working as intended?

[segra]

23 hours ago, MrFlibble said:

It should be noted that the blur is certainly not part of the "original look" - the non-square pixels were pretty sharp on 4:3 CRT screens unless their tuning was messed with. The blur is an inevitable side-effect of LCD screens being incapable of drawing non-square pixels.

Ah, right now I understand...

Quote

I should say it's a pity that you're not going to update the project further. Perhaps add a minor fix to get the demo working as intended?

Yeah I'll look into that once I've got time, I'm not really sure how much work will be involved though... as they appear to have hacked up the EXE from my experiments (it contains missions all the way to some of the last scenarios... and just skips certain ones / phases in between)

I do find it strange they went for this approach, over just removing the maps from the data file and renumbering the ones they wanted to keep... but maybe they lost the tool used to compress the data

 

Also, has anyone noticed that the forum, when you quote someone and click to break the quote up... when you start typing, it comes out backwards? like its typing from right to left, instead of left to right?

 

[drnovice]

Quote

The blur is an inevitable side-effect of LCD screens being incapable of drawing non-square pixels

If moderns OS runs with LCD monitors, why persist to want aspect correction? How many people runs Win10 in a cathode ray tube monitor?

Demo files regards the logic on exe, but I could be obtained simply examining the behaviour "in game" of the demo, and add some c++ switch into opensource code. The engine is the same because of the demo "logic" is only delegated on exe and not on data pack file (we have clarified is the same between demo and final release, apart the ending closing image).

Mostly important would be the remaining sprites decoding for CF2 that are new and different respect CF1. Remember that one good aspect of opensource project is precisely to let other people to take code and add/implement new/missing stuff from the base release. Maybe sooner or later will release 2.0 or more.

 

[MrFlibble]

23 hours ago, drnovice said:

If moderns OS runs with LCD monitors, why persist to want aspect correction? How many people runs Win10 in a cathode ray tube monitor?

Aspect correction is needed to maintain the intended look of the graphics. The developers were generally aware of the non-square pixels in VGA mode 13h, and they designed graphics for the game so that they would have correct proportions when viewed on the 4:3 screen. However if the same graphics are viewed now on a screen that only supports square pixels, they will appear distorted ("squashed" vertically).

Here's a very good example. The GDI logo in Command & Conquer has the shape of a circle - we know that for sure because Westwood Studios released a high-resolution render of the logo among the promotional materials. However, if you run the DOS version of the game without aspect correction, the logo on the sidebar will look like this:

The logo is noticeably shorter on the vertical axis, making it oval instead of round. Yet if you apply aspect correction, you'll get this:

Now the logo is near-perfectly round, which is the intended look of the graphics. Also notice that the perspective of the buildings is somewhat distorted on the non-corrected screenshot as well if you compare it to the one where the intended aspect ratio is maintained.

Further evidence can be found if you compare the VGA and SVGA modes of the same game, if both were available (e.g. Descent II, Duke Nukem 3D), or if a VGA game had a port to a system which only supports high resolutions (e.g. the Mac ports of Descent or Warcraft). Also the Doom Wiki has a very good article on the issue.

Of course, not every developer took the aspect ratio into account. It might very well not be the case with Cannon Fodder actually. However, this is not a reason to disregard the issue entirely.

[drnovice]

Yes it's true MrFlibble: from CGA to VGA mode 13h (used to have 256 colors) then was applied X Mode. So it's plausible to think that many designers based on it during their 320x200 drawings after the use of this method and the spread of 4:3 CRT monitors as standard.

I tried to use aspect correction for EOB2 (Eye of the Beholder II): both DosBox and ScummVM the final effect is a bit blurry (ScummVM less blurry than DosBox) on my LCD laptop monitor, so with SDL seems can't replicate perfectly the Mode X when processed images are stretched, but maybe it needs to try on many other monitors and graphics cards.

Edited March 23, 2016 by drnovice

[MrFlibble]

20 hours ago, drnovice said:

I tried to use aspect correction for EOB2 (Eye of the Beholder II): both DosBox and ScummVM the final effect is a bit blurry (ScummVM less blurry than DosBox) on my LCD laptop monitor, so with SDL seems can't replicate perfectly the Mode X when processed images are stretched, but maybe it needs to try on many other monitors and graphics cards.

Judging by the screenshots at MobyGames, EOB2 is not a Mode X game. Screenshots of a game using this graphics mode will be in 320x240, like here and here for example.

The blur is inevitable if you use aspect correction at low resolutions, as explained in detail in the article I posted above. However, in DOSBox you can get rid of the blur by running a game in fullscreen mode at the host system's screen resolution (provided that it is higher than 640x480) with the fullresolution=desktop setting and use an output method that does nearest-neighbour scaling (e.g. DirectDraw - at least, if you're running DOSBox SVN Daum). That way, DOSBox will still double every nth row of pixels to stretch the image, but it will not be noticeable because the original pixels are a lot larger (example screenshot). This is in fact the preferred method of playing VGA games in DOSBox if system resources permit it.

[drnovice]

fullscreen=true
fullresolution=1024x768

aspect=true
scaler=none

Very much blurry

[drnovice]

With Dosbox Daum: no blurry but the ratio letters (look at "J" letters of Jools and Jops, are completely different) isn't maintained... I don't think is the right solution.

[MrFlibble]

14 minutes ago, drnovice said:

With Dosbox Daum: no blurry but the ratio letters (look at "J" letters of Jools and Jops, are completely different) isn't maintained... I don't think is the right solution.

This is a close as it gets to how the game actually appeared on a typical DOS computer screen.

However, Cannon Fodder was not originally a DOS game but a port from Amiga, and I have no idea what the video modes of that system could be. It should be noted though that Ray Hardgrit stretched the screenshots to 4:3 in his review of the game, which he apparently played on real authentic hardware. It turns out to be not 4:3 but an upscale of 320x224, and the original images he used are in this resolution.

[drnovice]

Yes I played originally Amiga version when I was boy, since I haven't got a PC in '90s. Indeed if you see on screenshots of review, the written are on 16:10 ratio respect 4:3 of ms-dos version.

Anyway with:

fullscreen=true
fullresolution=desktop
output=ddraw

aspect=true
scaler=normal2x

seems better for DosBox Daum. (even if a bit of blurry remains, it seems to me).

[drnovice]

Uhm, it seems definitively that the reason of the blurry (more or less marked) it was the scaler. If scaler=normal3x is less blurry on fullsceen respect scaler=none & fullscreen.

[segra]

Although this really has nothing to do with the topic at hand, i figured, why not, because....

The Amiga version owns that crappy dos one (note: the graphics where all completely re-drawn for the PC Port)

Unfortunately, these photos where not taken for closely examining the contents of the screen, and I really can't be bothered going and getting my Amiga(s) / games out of storage again at this point in time :)

But it does show a nice black border around the screen...

Which the top and bottom bars are missing during the intro...

And for some strange reason, i cant find any of the photos of the actual game being played...

 

[MrFlibble]

On 23.03.2016 at 1:07 AM, segra said:

The Amiga version owns that crappy dos one (note: the graphics where all completely re-drawn for the PC Port)

I'm not sure what you mean by that. I've compared a couple of shots from the Amiga and DOS version found at MobyGames, and the only difference apart from the screen dimensions seems to be that the DOS version takes advantage of an 8-bit palette while the Amiga one has that weird (from the IBM PC perspective that is) 32-colour palette. The sprite dimensions were apparently not corrected for the DOS aspect ratio, which is, sadly, not an uncommon practice with cross-platform ports of the era.

On 23.03.2016 at 7:02 PM, drnovice said:

Uhm, it seems definitively that the reason of the blurry (more or less marked) it was the scaler. If scaler=normal3x is less blurry on fullsceen respect scaler=none & fullscreen.

The scaler variable simply determines if the pixels should say unchanged, or be doubled (default), tripled, quadrupled etc. So I guess the larger the pixels, the less noticeable the blur. But the idea here is to pick an output method (which is something unrelated to the scaler) that doesn't cause blurring in the first place.

[drnovice]

To integrate some info about real Amiga aspect ratio:
http://coppershade.org/articles/More!/Topics/Correct_Amiga_Aspect_Ratio/

Best recap could be:

Quote

Squashed and stretched graphics in some games Game graphics drawn in the USA (such as Zany Golf, Outlands) look very squashed (compressed vertically) on a PAL display because they were drawn on these pre-stretched NTSC displays.
Similarly, PAL games that run on NTSC have graphics that look tall (stretched vertically). There was just no way they could spend the money to draw two sets of graphics, not to mention fit them on disk.

I think Cannon Fodder porting from Amiga to Dos shouldn't have Dos correct aspect ratio, since 320/200 (16:10) already maintains correct size of drawing into game.

[MrFlibble]

Thanks for the link to this article! The question sure is complicated due to the difference between PAL and NTSC screen sizes.

I agree that the source port should give an option to display graphics as intended by the artists who were drawing for the Amiga. However DOS users back in the 90s probably had no way to avoid the 4:3 stretching unless they adjusted the shape of display on their monitors manually (provided that they knew beforehand that the graphics in the game were not displayed according to the artists' intention). Which means that a 320x200 image stretched to 640x480 is technically the "correct" way of rendering the DOS version because that is what the users saw (but not what the designers originally intended).

Then again, the technicalities of the DOS version can probably be ignored as it is "non-original", i.e. secondary to the initial Amiga release.