CompuServe Messages

Honestly Nick. The advantage you get between Assembler over C stays, irregardless of how much code is involved. I've got almost quarter meg of assembler code in my game, so far… and I'll bet it would be a megabyte if in Compiled C. Not only that, it'd run MUCH MUCH slower! You can do intelligent things with registers that cannot be expressed in C… Like : MULS D0,D1 DIVS D2,D1 Which very few C compilers will ever be able to intelligently generate! What it does, is multiply two 16bit numbers, giving a 32bit result in d1, and then immediately after it, divides the 32bit result by a 16bit quantity in d2, leaving the result as a 16bit result in D1. In C, the above code would probably have been over 400% larger, and at *LEAST* 400% slower, cos it would have done everything as 32bits to gain the same effect. Either that, or the C compiler is *DAMN GOOD* but I've not seen one that IS, … yet. For an example of some Assembler on Amy, look at Aterm.S in the download library here online. It assembles down to about a 6K object code which is equivolent to about a 30K compiled C program that does a similar thing. I'm not disputing the obvious advantages of C, namely that program development is FAR easier, and less bugs are resultant because register and status problems are avoided, since they are no longer required. However, you do NOT get something for nothing:- and you lose out on being 'in touch' with the machine you are programming. Thus code cannot be TOTALLY optimised. My work requires that I get the most performance out of a machine that it can give. That means programming in optimised assembler simply to get the 'video frame rate' as fast as possible. As an example of a poorly programmed game written in C, take a look at Artic Fox by Electronic Arts. Since it was written in C, it is VERY slow!! At best 2 frames per second.. and usually less than 1! Just imagine how much faster that program would be if written in machine code!! — Jez.