(I hope this is the right forum for this..)
Chap A
| Graphics
API's completely extract the graphics cards so the programmer doesn't
have to worry about dealing with each type of card a user might have.
There is no reason he should ever have to or even want to deal directly
with the graphics card.
He also doesn't have to have a language with a direct interface to assembley. Some languages are better then others for a project like this, but being able to paste assembley into the code is not a requirement. |
Chap B
He'll have to directly interface with hardware so that he develops low resource algorithms. For example, look at a high level language such as Java, VB, or even Python. Then look at a language like C/C++ or ADA. Then look at ASM. When you develop algorithms in each of these languages (yes I know that the first 3 all have run times) You'll see that algorithms that are in ASM use less resources then even in an compiled architecture dependent language that's medium level. Specifically he'll need to work with ASM for direct interface with not only the GFX card (dependency issues, you don't want to call on an external library if you don't have to - its resource and security issues), but also the network card (especially with Windows).
Chap A
| This ins't the 90's anymore. Although ASM can be fun to work with, and helpful if you are making a AAA engine, you don't need to know ASM anymore to make games. Hell the only thing normally even written in a compiled language anymore is the engine. Everything else is normally in scripts. |
This chap says
mmonte
Thanks Jack.
Marco Minerva
Thanks "lots n lots"
Caralyn
hehe, this is a bit of an age-old classic really... some habits die hard it seems
Real Programmers like to get down-and-dirty with their hardware and prefer to write in assembly code and try to fine tune their application to make every cycle and every byte count. In the good old days (and to some degree still true on games consoles) this was required - resources were limited.
However, as complexity and available resources are increased this ceases to become so important and can actually be counter-productive. If we consider the context of GPU's - not only is direct access to those hard to achieve, the combinatorial explosion that you'd get (I can think of at least 10 different chipsets/generations still around) just makes it unfeasable. Abstraction is your friend here.
Then there is the programmer's productivity to consider - writing assembly code is slower (unless you're some sort of assembly guru) than writing in a HLL. Tracking down bugs can be more time consuming and maintenance can be a nightmare. The sort of things that make management really unhappy
It is debatable, but with a mature platform (such as current desktop computing) the tools available are exceptionally good. The JVM's and various frameworks are very well written in some cases, and can be very good for performance. The compilers for native languages (such as C/C++) can do an exceptional job at making use of CPU instruction sets and features (e.g. SSE and MMX) as well as optimizing the HLL code. I would put money on it being difficult to find many Assembly programmers that could write better/faster code than a decent optimizing C/C++ compiler.
But, each to their own really... you're not likely to get everyone to agree on what I've just typed.
My personal preference is to "Get it right, then get it tight". I write my code as it's intended to function, then I go back and profile it, review it (etc..) and optimize the parts where it matters.
Jack