Home of TAPEGRO, the Js game framework of the future

Configuring Tapegro for MS-DOS

You'll likely want use_vsync not to be set, as not all graphics modes support vsync anyway.
The window_w,window_h,color_depth must correspond to an existing graphics mode. 320,200,8 is the classic mode 13h, highly recommended.

Other things to keep in mind

Be careful with filenames - keep all your resources in MS-DOS 8.3 filename format (8 for name, 3 for extension).

Testing performance under DOSBox

The following two lines can be typed into DOSBox to simulate a 486:

core=normal
cycles=26800

Alternatively, use cycles value of 77000 for a Pentium I.
One can see that performance is often not so brilliant - if you want your game played like a real MS-DOS era PC could, you will have to optimise carefully. See optimising for MS-DOS, below.

Things that don't work in MS-DOS

Currently the differences below are caused by deficits in the older version of Allegro used:

TEXT_RIGHT has no effect and will default to TEXT_LEFT
Sprites which are rotated, scaled or both will ignore flips
LoadFont does nothing and just returns the default font
MaskedStretchBlit does an unmasked stretch blit instead
GetMIDILength always returns 0

Optimising for MS-DOS

It seems most often what will take the most time will be Js execution, not rendering.
Some tips follow:

Use macros where possible

You can invoke gcc as below to use it to preprocess files not in the C language:

gcc -E -P - < main_src.js > main.js

Knowing that, changing this

function Move(obj){
	obj.x += obj.dx;
	obj.y += obj.dy;
}

function Collision(a, b){
	return (Math.abs(a.x - b.x) < (a.radius + b.radius) && Math.abs(a.y - b.y) < (a.radius + b.radius));
}

into this

#define Move(obj)	\
obj.x += obj.dx;	\
obj.y += obj.dy;

#define Collision(a, b) (Math.abs(a.x - b.x) < (a.radius + b.radius) && Math.abs(a.y - b.y) < (a.radius + b.radius))

can enable a significant performance improvement, due to the cost of function calls.