• Please review our updated Terms and Rules here

Borland Turbo C 2.01 vs Turbo C++ 3 for CGA game

D

discolando

Member
Joined
Mar 8, 2020
Messages
16
Location
Kansas City, KS USA
I've put together a proof-of-concept graphical interactive fiction game engine (think OO-Topos, Mindshadow, etc...) using Borland Turbo C 2.01. It's intended to run on an original IBM 5150 with CGA graphics and so far requires roughly 256k RAM. It's also using ASM routines I've written for screen drawing and implementing the UI. It's all running fairly well and I have original hardware I'm testing on to confirm.

I'm far enough along to where I think I could release this for people to test, but I'd like to do another major iteration through the project to address inefficiencies and otherwise update things I've learned how to do better. While I'm doing this, would there be any advantage(s) gained in performance, memory footprint, or code organization in migrating this to Borland Turbo C++ 3.0? All other things being equal, would the memory footprint grow or shrink? Should I expect game logic, keyboard input response, etc... to perform the same as it is now? Is the C++ compiler new(er) enough that it would make any significant difference?

Thanks!
 
Usually my experience with newer versions tend to increase code size. Here is a sample hello world programmed with various Borland compilters.

You will save code size by making sure debugging is turned off and also using the smallest memory model that your program will support.

Code: 
 8,170 _BC2.EXE
8,810 _BC31.EXE
5,398 _TC1.EXE
5,750 _TC15.EXE
8,358 _TC2.EXE
8,768 _TCPP1.EXE
8,665 _TCPP3.EXE
10,076 _TP2.COM
11,410 _TP3.COM
1,968 _TP4.EXE
1,840 _TP5.EXE
1,920 _TP6.EXE
2,192 _TP7.EXE
 
Most of the size differences between the C compilers shown above has more to do with the size of the runtime library than the quality of code generation. I compiled COVOIDS with MSC 5.1, BC 2.0 and BC 3.1. The speed and size difference was pretty inconsequential, but my gut feel that BC31 was slightly faster and slightly larger. Unless there is some feature you need from a newer compiler, I wouldn't stress about it. Anything really speed critical should be in assembly anyway.
 
Last edited:
I’d recommend trying Open Wacom with CodeBlocks. You can build real mode software in a modern environment with it. The source will require some updates but not much.
 
Of course, all this is a matter of opinion :). I tried Open Watcom some time ago and was fairly impressed by its performance and easiness to use for 32 bit protected mode + DMPI, and Win32 command line projects. Nevertheless, I was less impressed by its 16 bit real mode performance. I ported a relatively advanced project I have from Turbo C++ 1.0, and this required to make too many changes to make it worth given the result.

The goals I pursued by porting it to Watcom were better overall performance (speed) and a smaller executable size. Regarding performance, I completely agree with Resman: in a DOS game, the peak of performance is going to be given by the quality of your assembly optimization for the critical parts (animations mainly), not the quality of the C compiler. Regarding size, both Borland's and Watcom's sizes were quite similar, not a much noticeable difference. But if I make a 32bit DOS project in the future, my choice will be undoubtedly Watcom. For 16 bit DOS, I'll stick with the Borland's compilers.

Regarding what Borland version to use, I pretty much agree with what was said before. I don't think there's a real advantage for a 16 bit DOS game using a later version such as Borland C++ 3.1. It has more code optimizations than the former versions but I don't think they would be noticeable on a game, plus the disadvantage of the executable code being a bit larger. TC++ 1.0 and later has the advantage of a much better IDE. Regarding TC++ 1.0, I must say that, in my experience, it's much more buggy than previous and later versions. For example, I have code that compiles flawlessly on TC 2.0 and BC++ 2.0 but gives a memory error on TC++ 1.0. Very much annoying. So my next step is probably downgrading to TC 2.0 (I use C, not C++) or upgrading to BC++ 2.0.
 
alank2 said:
Usually my experience with newer versions tend to increase code size. Here is a sample hello world programmed with various Borland compilters.

You will save code size by making sure debugging is turned off and also using the smallest memory model that your program will support.

Code: 
 8,170 _BC2.EXE
8,810 _BC31.EXE
5,398 _TC1.EXE
5,750 _TC15.EXE
8,358 _TC2.EXE
8,768 _TCPP1.EXE
8,665 _TCPP3.EXE
10,076 _TP2.COM
11,410 _TP3.COM
1,968 _TP4.EXE
1,840 _TP5.EXE
1,920 _TP6.EXE
2,192 _TP7.EXE
Click to expand...

This list can expanded if you compile with one version of the compiler but use the LIB directory of a different version.
For Commander Keen 4 v1.4 id Software compiled the code with Borland C++ 3.0 but used the LIB directory of v2.0.
 
Interesting - why would someone use an older version LIB directory?
 
I don't know. To create a smaller executable? Or they just forgot to change a setting in the compiler?
 
On second thought, Commander Keen 4 versions before 1.4 aren't compiled with Borland C++ 3.0, probably with v2.0. For Keen 4 v1.4 id Software just used their old v2.0 .PRJ file in v3.0 without updating the directory settings.
 
You must log in or register to reply here.
Back
Top