Why isn't ASM the game language of choice?

[Keith Elder]

James David Chapman wrote:
>
>
> A few people have compared early pac man with the modern games we
> see today, and laughed. Yet I have no doubt the original pac man
> *was* as complex as the game engines of today. Just think about it...
> Were the programmers of then less clever than us? Why didn't they
> come up with DOOM? The answer is of course simple, they were packing
> features into machines which were too small, and running amazing
> routines on processors which were too slow. They achieved the
> impossible and their code was like poetry, and like poetry, there had
> to be strict limits for it to work. But, how often do you find
> beautiful code like that today?
>

I agree wholeheartedly. I have a hard time trusting any programmer who
has not paid their dues crafting an assembly game on a commodore 64, or
apple ][, or any other 8 bit platform. My brother wrote and sold a very
fast game he wrote for a VIC-20 that he wrote in machine language.
Note: Not assembly, I mean _machine_language_! No symbols, no equates.
He used a machine language monitor, and if he wanted a branch, he
counted bytes to find where to branch to. If he wanted to write a
string to the screen, he looked up the ASCII values and typed them in.
Yes, we have tools that allow us to skip those tedious tasks, but I
think in the process we have become disconnected from the intimacies of
the hardware.

I think that many of the programmers from ten years ago were pulling
performance out of the hardware they had in a way that no one is doing
now. Too often, in this very newsgroup, I have heard too many questions
about code performance answered with a derisive "You only have a pentium
100? Get a modern system, DUDE! That'll fix your problem."

Ah, well. Nostalgia is a potent drug ;)

Keith Elder
el...@cdsnet.net

[Jason Shankel]

James David Chapman wrote:

> I have agreed that non crucial code can be written in C, though as
> you may have guessed, I *would* write that init routine in asm. I am
> not sure what it is, but I tend to associate bad coding with C. The
> number of terrible init routines I have seen, only goes to re-enforce
> this view.

You can write bad code in any language. The question is not how crucial
code is (a save-game function is crucial), but rather how fast it has to
be. If I can code a save game routine in an hour in C, or in a day in
ASM, I'm going with C, even if the ASM version could speed me up some
(doubtful, since these routines are usually limited by file access
time).

> >First, asm is no longer necessary for many of the low-level tasks under
> >Windows.
>
> As long as you accept the overhead which Windows imposes.

Those of us *game* *programmers* you identified in your original post
have to accept the overhead Windows imposes, at least those of us who
develop professionally for the PC.

>
> >Second, when 1% of the code takes 99% of the runtime, why write the
> >other 99% in asm to gain perhaps a 0.5% speedup? Why not just write the
> >1% in asm to gain perhaps a 20-50% speedup?
>
> I agree, I *know* the actual programming in C is faster. I am
> arguing the other way since I see the code produced by C compilers as
> bloated and slow.

The point is that even if all of the C code were magically transformed
so it executed instantaneously, you would only notice a 0.5% speedup.
It is simply not worth spending even a microsecond, much less the
additional MONTHS pure asm implies, to chase that kind of negligible
improvement. That time is better spend focusing on making your C code
readable, portable and maintainable and making your assembly fast.

> >1. DirectX/OpenGL
>
> Is not really the issue here, it may be a big thing in the world of
> windows, but assembly programmers have had full video control for
> years.
>

You cannot get such access to 3d hardware in any other way. You simply
do not have the option of register programming these cards, you must use
an API.

> >5. C code is more readable, less buggy on average
> >3. C compilers beat structured asm
> >4. Optimized (non-structured) asm takes too long to write
> "Takes too long to write". That is the answer to my question. Thank
> you.
This is an important issue. Most of us are on schedules.
Boss: "How long will that main menu routine take?"
Programmer: "Two days, or two hours, if I use C."
Boss: "Use C."
Programmer: "But it'll be 10-20% slower!"
Boss: "It's a menu routine, I don't give a frag."

<RANT>
The sentiment, I think, myself and others are trying to convey is not
that there is no regard for assembly programming, but rather that
advances in technology have shifted our priorities.

Executable size, for example, is now MUCH less of an issue than it was
even a few years ago. When modern games require 16-32 megs to run, a 3
meg executable size is not even considered a factor.

Execution speed for outer loop functions is less of a critical issue.
General responsiveness and good speed are, of course, always desirable.
But high level languages provide adqequate speed for anything which
doesn't have to be rip-roaring fast. And, despite your contention, most
of us are more productive and produce better code in these languages.

Among the new priorities:
Portability. Windows may dominate the desktop, but the console
landscape changes radically every few years. Sure, your engine code
will probably have to change, but it would be nice if you could move
your simulator from the PC to a console without TOO much pain.

Keeping up. We're living under Moore's curve and it's getting harder
every year. As you point out, years ago, hardware was RELATIVELY
stable. You could rely that techniques you learn today will be useful
in two years. Now we're expected to become overnight experts in
technologies which will be obsolete in less than a year (where did all
that D3D 3.0 experience go when DrawPrimitive came out? How useful will
DrawPrimitive be when Farenheit comes out? etc). Assembler code you so
lovingly craft at the beginning of a project is likely to be sub-optimal
on the hardware which exists when you ship. Working in C or C++ or some
such until near the end of your project and then VTuning for ASM
optimization (as long as you've been writing decent C code) is a better
strategy than optimizing today for a product that's a year or two away.

Ship it ship it ship it. Like it or not, we live with (often
unreasonable) deadlines. If your game is god-awful slow, that's bad.
But otherwise, your marketing department and your friendly neighborhood
VP of Production are not likely to give you an extra six months on a
project so you can get it 10% faster. That may not sound very
idealistic...but this is real life. Honing and crafting and obsessing
over your pet routines is fine for a weekend passtime, but the reality
is that there are WAY more jobs than people to fill them. As
programmers, we are SWAMPED with tasks. We're smart people, working at
full steam. We simply cannot afford ANY slowdown, certainly not for a
few measly percent on non-speed-critical code.

Code reuse. Team 'X' wants our renderer, we want Team 'Y's app
framework, some guys in our London office have a cool LOD terrain
system. Companies (and especially big conglomerates like...I won't name
names) are moving more and more to preventing their people from
reinventing each other's wheels. This means modular libraries with
abstract interfaces. While such stuff is certainly possible in ASM
(anything is, after all), it is easier in C (and, in my opinion, almost
simple in C++).

As for the "I'm tired of being forced to upgrade every year" thing...I
sympathize, believe me. I think that Moore's Law has left a lot of
consumers in the dust. The fact is, unfortunately, that we are driven
to hit the high-end machines. If your title runs well on a low-end
machine, that's an indication that you are not "cutting edge". This
holds even if your game is 100% pure uber-optimized assembly. Faster
machines give you more clock cycles: use em. Now I, personally, don't
believe that this attitude should always prevail. After all <plug>
SimCity 2000 <\plug> is still a great revenue title, despite
six-year-old technology. Nonetheless, this attitude is common among
those who write the checks.

Sorry for the rant, but you asked why ASM has fallen out of favor. ASM,
in my experience, is certainly not dead. It is just not as universally
appropriate as it used to be. That does not diminish its importance.

<\RANT>

--
Jason Shankel,
Maxis, Inc.

s h a n k e l
at
p o b o x . c o m

[James David Chapman]

The results of my earlier trolling of various threads on this group
were predictable, if a little sad. However, it was not my intent to
aggravate for the sake of it. There is a very serious point here.

A few people have compared early pac man with the modern games we
see today, and laughed. Yet I have no doubt the original pac man
*was* as complex as the game engines of today. Just think about it...
Were the programmers of then less clever than us? Why didn't they
come up with DOOM? The answer is of course simple, they were packing
features into machines which were too small, and running amazing
routines on processors which were too slow. They achieved the
impossible and their code was like poetry, and like poetry, there had
to be strict limits for it to work. But, how often do you find
beautiful code like that today?

Well you don't come across it very often. Yet, hidden deep at the
bottom of almost all the great games, you *will* find it... the
reason? You just can't run massive numbers of instructions through
the processor every 1/30th sec. You have to have a highly optimised
machine language game engine. The engine must fit into the processors
cache, it must be interleaved, it must be written again and again,
until it is the most efficient it can possibly be.

Now, I accept entirely that unoptimised ASM will produce code
comparable with a C compiler, and that it can take longer to produce.
However, at some stage, if you want to write a *game*, you are going
to have to get your hands dirty. You are going to have to write
machine level instructions. As I have said, inner game loops *must*
be machine code of the highest quality. Support routines such as
sound, video, timer etc. all require low level hardware coding.
Machine coding. Any movement of pixel data must be done with
assembly, since most of the time in a gameloop is still spent doing
just that... and as for maths, clearly there is no alternative. Even
efficient memory management must be done in assembly. So what else is
there? The menus. Okay, you can do them in C if you want, but if
you try to code everything in C, only dropping out occasionally to a
bit of inline, then when are you ever going to learn the skills
required to write those optimised game loops? I am unashamed to say
that it took me 5 years to learn the m/c skills needed for a game
engine, and now I find that these skills are dying out, due to what I
see as the inappropriate, over usage of C.

You can never complain about Microsoft churning out average software
like a sausage factory, without accepting that C must take some of the
blame. C *is* easier to write. Assembly *does* take more time to
write, and *is* harder to read. This is not a bad thing, and far more
crucially, it is not, as Jason suggested, an anti-commercial thing.
We can argue about Microsoft and a whether quality is their Achilles
heal another time, but you must agree that where games are concerned,
people buy quality, and if games can be improved by machine code, then
the industry had better wake up and start hiring, or it may find that
a different section of the unwashed will be driving the Ferraris.

I had not intended a 'my language is better than yours' debate, with
all the tedious personal attacks and insinuations about programming
style that USENET is famous for. I was simply reminding you that
although C is dominant in the games market place today it need not
always be that way. It seems people are confusing the work they do in
their business programming with games design.

I am interested in why *you*, the *games* programmers are
programming in what I, and the programmers of yesteryear would
consider a mid level language, the only true benefit of which is
portability, which clearly *is* a benefit, but one which comes at a
price. The price of making your code non-machine specific is speed.
It will always be so. You cannot claim that C gives both, there must
be a compromise somewhere.

For me, the compromise it too great. For you it isn't. I am
interested to understand why.

James David Chapman.

[Thomas Womack]

James David Chapman <jc...@nospam.globalnet.co.uk.I.said.NO.spam> wrote:

: A few people have compared early pac man with the modern games we

: see today, and laughed. Yet I have no doubt the original pac man
: *was* as complex as the game engines of today. Just think about it...
: Were the programmers of then less clever than us? Why didn't they
: come up with DOOM? The answer is of course simple, they were packing
: features into machines which were too small, and running amazing
: routines on processors which were too slow. They achieved the
: impossible and their code was like poetry, and like poetry, there had
: to be strict limits for it to work. But, how often do you find
: beautiful code like that today?

: Well you don't come across it very often. Yet, hidden deep at the
: bottom of almost all the great games, you *will* find it... the
: reason? You just can't run massive numbers of instructions through
: the processor every 1/30th sec.

Ten million's enough for me ...

You have to have a highly optimised
: machine language game engine. The engine must fit into the processors
: cache, it must be interleaved, it must be written again and again,
: until it is the most efficient it can possibly be.

Nope; on current hardware, the game engine can consist of a series of
calls to DrawPrimitive at the bottom of a loop written in interpreted
BASIC, and will still run faster than Michael Abrash could possibly
imagine. HARDWARE ACCELERATION WINS.

Tom

[Matt Craighead]

James David Chapman wrote:
> Well you don't come across it very often. Yet, hidden deep at the
> bottom of almost all the great games, you *will* find it... the
> reason? You just can't run massive numbers of instructions through

> the processor every 1/30th sec. You have to have a highly optimised

> machine language game engine. The engine must fit into the processors
> cache, it must be interleaved, it must be written again and again,
> until it is the most efficient it can possibly be.

You need SOME of the game to be heavily optimized. Not all. Most code
is non-critical. Would you really make your initialization code in
asm instead of C?

> Now, I accept entirely that unoptimised ASM will produce code
> comparable with a C compiler, and that it can take longer to produce.
> However, at some stage, if you want to write a *game*, you are going
> to have to get your hands dirty. You are going to have to write
> machine level instructions. As I have said, inner game loops *must*
> be machine code of the highest quality. Support routines such as
> sound, video, timer etc. all require low level hardware coding.
> Machine coding. Any movement of pixel data must be done with
> assembly, since most of the time in a gameloop is still spent doing
> just that... and as for maths, clearly there is no alternative. Even
> efficient memory management must be done in assembly. So what else is
> there? The menus. Okay, you can do them in C if you want, but if
> you try to code everything in C, only dropping out occasionally to a
> bit of inline, then when are you ever going to learn the skills
> required to write those optimised game loops? I am unashamed to say
> that it took me 5 years to learn the m/c skills needed for a game
> engine, and now I find that these skills are dying out, due to what I
> see as the inappropriate, over usage of C.

First, asm is no longer necessary for many of the low-level tasks under
Windows. Only driver writers need use it in most cases. Software
renderers are almost dead for 3D, and 2D games run blindingly fast these
days -- you hardly need to optimize even if DX's Blt or BltFast doesn't
support what you want. You definitely no longer use it for sound or
timer code.

Second, when 1% of the code takes 99% of the runtime, why write the
other 99% in asm to gain perhaps a 0.5% speedup? Why not just write the
1% in asm to gain perhaps a 20-50% speedup?

> You can never complain about Microsoft churning out average software

> like a sausage factory, without accepting that C must take some of the
> blame. C *is* easier to write. Assembly *does* take more time to
> write, and *is* harder to read. This is not a bad thing, and far more
> crucially, it is not, as Jason suggested, an anti-commercial thing.
> We can argue about Microsoft and a whether quality is their Achilles
> heal another time, but you must agree that where games are concerned,
> people buy quality, and if games can be improved by machine code, then
> the industry had better wake up and start hiring, or it may find that
> a different section of the unwashed will be driving the Ferraris.

All-asm is no longer appropriate for games, though.

> I am interested in why *you*, the *games* programmers are
> programming in what I, and the programmers of yesteryear would
> consider a mid level language, the only true benefit of which is
> portability, which clearly *is* a benefit, but one which comes at a
> price. The price of making your code non-machine specific is speed.
> It will always be so. You cannot claim that C gives both, there must
> be a compromise somewhere.

"yesteryear" is the key word. Windows totally shifted the game
programming model. You no longer do most of the low-level coding
yourself these days.

> For me, the compromise it too great. For you it isn't. I am
> interested to understand why.

1. DirectX/OpenGL
2. Sometimes C is "good enough"

3. C compilers beat structured asm
4. Optimized (non-structured) asm takes too long to write
5. C code is more readable, less buggy on average

--
Matt Craighead
Utumno developer: http://www.citilink.com/~craighea/utumno/

[James David Chapman]

Matt Craighead <crai...@citilink.com> wrote:

Interesting points Matt, thanks for the input. Naturally I am not
likely to agree with them am I? But, hey, that's the great thing
about evolution, it creates different people, who believe very
different things, and the ones who are right, end up more successful.
It will be interesting to see where the future of gaming lies.

>You need SOME of the game to be heavily optimized. Not all. Most code
>is non-critical. Would you really make your initialization code in
>asm instead of C?

I have agreed that non crucial code can be written in C, though as
you may have guessed, I *would* write that init routine in asm. I am
not sure what it is, but I tend to associate bad coding with C. The
number of terrible init routines I have seen, only goes to re-enforce

this view. There seems to be a great deal to be said for spending
*more* time on a bit of code. Asm forces you to do just that, and as
such means you end up with a much more robust bit of work. C lets
you get away with murder, and many people do just that.

>First, asm is no longer necessary for many of the low-level tasks under
>Windows.

As long as you accept the overhead which Windows imposes.

>Second, when 1% of the code takes 99% of the runtime, why write the
>other 99% in asm to gain perhaps a 0.5% speedup? Why not just write the
>1% in asm to gain perhaps a 20-50% speedup?

I agree, I *know* the actual programming in C is faster. I am
arguing the other way since I see the code produced by C compilers as
bloated and slow.

>"yesteryear" is the key word. Windows totally shifted the game
>programming model. You no longer do most of the low-level coding
>yourself these days.

You do if you think you can do it better. (faster/smaller/less
buggy). I am fed up with having to change my computer every year, and
going the Windows route forces this upon us, and our customers. In
the 'good old days' :) computers didn't change every year, and yet,
year by year the programs *did* get better... because the coders got
better. Nowadays I fear that the coders will always rely on the next
generation of computer to solve all their problems for them, rather
than get a good book on Asm from the local library.

>1. DirectX/OpenGL

Is not really the issue here, it may be a big thing in the world of
windows, but assembly programmers have had full video control for
years.

>2. Sometimes C is "good enough"

I agree already! I know C is good enough for certain routines. I
am disagreeing with you as to *which* ones, and trying to show you how
asm can help produce better code, even when speed is not an issue, as
is the case with non-inner loop code.

>5. C code is more readable, less buggy on average

Hmm, more bugs seem to slip by the net with C, with asm, they tend
to crash the computer, so the developer, rather than the end user, has
to spend the time sorting them all out.

>3. C compilers beat structured asm
>4. Optimized (non-structured) asm takes too long to write

"Takes too long to write". That is the answer to my question. Thank
you.

James David Chapman.

[Matt Pritchard]

Matt Craighead (crai...@citilink.com) wrote:

: 1. DirectX/OpenGL
Hardware is Hardware. No replacing it.

: 2. Sometimes C is "good enough"
Sometimes C++ is much better.

: 3. C compilers beat structured asm
Disagree - been there, ran circles around the best the complier could do

: 4. Optimized (non-structured) asm takes too long to write
Disagree - been there, wrote that, shipped on time

: 5. C code is more readable, less buggy on average
Disagree - depends on the programmer
--
-Matt P

_______________________________________________________________________________
Matt Pritchard | Antique Computer & Game System Collector
matt...@netcom.com | Assembly Language Programming Guru
via Dallas, Tx dialup | Article Writer/Game Programmer/Developer

[Pat Smith]

James David Chapman wrote:

> >2. Sometimes C is "good enough"

> I agree already! I know C is good enough for certain routines. I
> am disagreeing with you as to *which* ones, and trying to show you how
>
> asm can help produce better code, even when speed is not an issue, as
> is the case with non-inner loop code.
>

> >5. C code is more readable, less buggy on average
>

> Hmm, more bugs seem to slip by the net with C, with asm, they tend
> to crash the computer, so the developer, rather than the end user, has
>
> to spend the time sorting them all out.
>

> >3. C compilers beat structured asm

> >4. Optimized (non-structured) asm takes too long to write
>

> "Takes too long to write". That is the answer to my question. Thank
> you.
>
>
>
> James David Chapman.

I'm glad to know someone else who realizes that almost all the
programers have about gone to shit. :)

Seriously, I perfered the old days where you wrote a program that
required your skills and knowedge for performance, now its all hardware
based. I thought the hardware was supose to open doors, not cover
sloppyness.

As for the C vs ASM deal, they both have their strengths. C is supose
to be a "quick and dirty" language where as ASM gets to the core of the
matter, and I'll admit I'm a shitty ASM programer.

One trick I've learned though for getting the "best of both worlds" is
for code that needs the speed of ASM is to write the code in C and then
generate a ASM dump from the compile. Not the best method in the world,
but its a start and you can "speed it up" and re-interduce it into a
program. That trick saved a couple ASM projects I had in school.

[BULLE]

James David Chapman wrote:
>
Lots of text removed, talking about why / whynot you should use
ASM in your game and if you do, how much.

>
> For me, the compromise it too great. For you it isn't. I am
> interested to understand why.
>

> James David Chapman.

One reason that comes to mind is that when you optimize your code, you
do that for one particular cpu. These days you have quite a lot of
different cpus, Those that come to mind are cyrix 6x86,686mx,mediaGX
amd k6 intel pentium / MMX / pro / 2 Centaur idt winchip. So it will
take some thinking and testing to get the code to work fast on all cpus
so you write it all in C and then optimize the obvius parts, taking care
to get it to run well on all cpus.

And if you like some companies devlope your game for totaly different
architectures, say windows95 / mac then you dont want to code so much
ASM. You would probably just optimize the most run parts here aswell.

One other thing is product cycle, for example how long are your game
going to take to write. Many of the bigest games have taken more then
one year to finish, it will be fun to see how long it will take to get
unreal / prey out for example. You dont want to start coding a game,
just to realise that when you are finnished all your asm is wasted
beacause now everyone are using intels p3 with MMMXXXXXXXXX cpus and
that cpu needs a very different instruktion order to get it to work at
its maximum.
--
mvh BULLE(Who Else?) KO-pyright 1998 all mooooos reserved

[Chris Lomont]

James David Chapman wrote in message
<6di8t3$9l6$1...@heliodor.xara.net>...
>

[snip about ASM needed for games, and C being slower]

With the release of the IA-64 chipset, the complexity of writing ASM
code will be so high that a C compiler will produce faster code than
probably every assembler programmer for large programs. The new
instruction format (go to intel's site, or x86.org) need encoded into
it a lot of information about data dependencies, instruction pairing,
and there are many, many rules. Intel has decided to remove the
instruction pairing and data allocation from the CPU to the compiler,
so the compiler will analyze the data stream and instruction stream
and encode the information into the machine code. To do this by hand
will be very error prone, unlikely to get the optimizations the
machine will, and very slow to develop any sizable piece of code.

And it seems this trend will continue, since many other hardware
manufacturers are looking at removing complexity out of the chip and
into the compiler. Good hand assembly will become almost impossible.

So I believe assembly will die out as more chips take this path. This
is one reason Playstation and N64 removed as much assembler code as
possible - the RISC chips involved have funky rules for assembler. The
IA-64 instruction set takes this to another level.

Chris Lomont

[James David Chapman]

Jason Shankel <JasonS...@seesig.for.address> wrote:

>James David Chapman wrote:
>Those of us *game* *programmers* you identified in your original post
>have to accept the overhead Windows imposes, at least those of us who
>develop professionally for the PC.

You might be forced to accept the Windows overhead, but you don't
*have* to buy into the philosophy 100%.

>The point is that even if all of the C code were magically transformed
>so it executed instantaneously, you would only notice a 0.5% speedup.
>It is simply not worth spending even a microsecond, much less the
>additional MONTHS pure asm implies, to chase that kind of negligible
>improvement. That time is better spend focusing on making your C code
>readable, portable and maintainable and making your assembly fast.

Hmmm, you're being a bit naughty here. Some people in this
newsgroup are pretending that an *entire* game project can be coded in
C, and still be the fastest it can possibly be. Even your mixture of
C and asm does not address a fundamental issue I raised... where are
the newbies in this group going to get their asm skills from if they
program in C most of the time?

>> >1. DirectX/OpenGL
>>
>> Is not really the issue here, it may be a big thing in the world of
>> windows, but assembly programmers have had full video control for
>> years.
>>

>You cannot get such access to 3d hardware in any other way. You simply
>do not have the option of register programming these cards, you must use
>an API.

Hardware manufacturers will soon learn not to keep their internal
specs to themselves.

>Boss: "How long will that main menu routine take?"
>Programmer: "Two days, or two hours, if I use C."
>Boss: "Use C."
>Programmer: "But it'll be 10-20% slower!"
>Boss: "It's a menu routine, I don't give a frag."

><RANT>

Heh, heh, rant away, I am enjoying what you have to say.

>The sentiment, I think, myself and others are trying to convey is not
>that there is no regard for assembly programming, but rather that
>advances in technology have shifted our priorities.

I appreciate *your* position, I am here to remind you not to go to
far in this shift, or you will see all the worst things about C take
over the industry. Yes, there *are* bad things about C!

>Executable size, for example, is now MUCH less of an issue than it was
>even a few years ago. When modern games require 16-32 megs to run, a 3
>meg executable size is not even considered a factor.

IT SHOULD BE.

This is *precisely* what I am talking about. The reason I mentioned
coders of the past, was because they did care. They could not stop
themselves from optimising because it was the only way to add new
features to the game. It still is! Are you really saying that you
could not use an extra 2Mb of data area for graphics or sound? I sure
could.

>Execution speed for outer loop functions is less of a critical issue.

I am happy to agree with this again.

>But high level languages provide adequate speed for anything which

>doesn't have to be rip-roaring fast.

I can't think what doesn't have to be rip roaring fast in a game.
Init routines have been mentioned, menus, maybe, if they are not
displayed by the game engine itself, everything else is inside some
kind of loop, so you'd better be careful.

Surely this attitude you have: "It doesn't matter how large the exe
is/almost all the code is non-time crucial", is linked to the reason
why people have to upgrade their computers every year? Surely you can
see that? :)

And surely you can see that, from my point of view, the number of
routines which are 'allowed' to be large and slow is increasing every
day! Never in a million years would *anyone* have agreed that low
level operating system functions should be done in anything other than
machine specific, machine code... and yet now it is accepted and
widespread. Doesn't mean its right.

You can't believe how frustrated it makes me, to find, games,
traditionally accepted as pushing *the machine* to the limits, (rather
than the 'cutting edge', whatever that is), have now been lumped into
"Heck Boss we can do it in C, and get the customer to pay for the
speed increase through hardware".

No. It is about time that the developers started to shoulder some
of the (very real) costs associated with speed, like they used to. My
point is, that a developer who does this *will* find they have a
commercial advantage, since people are getting sick of upgrading,
*very* expensive machines.

>Among the new priorities:
>Portability. Windows may dominate the desktop, but the console
>landscape changes radically every few years. Sure, your engine code
>will probably have to change, but it would be nice if you could move
>your simulator from the PC to a console without TOO much pain.

There comes a time when you have to just sit down and say, "this
game is designed for this machine", your customers are clearly paying
for the portability of your code as well. You better hope they don't
wise up.

> Assembler code you so lovingly craft at the beginning of a project is likely to be sub-optimal
>on the hardware which exists when you ship.

I really don't find this. Routines just run faster and faster.

>Ship it ship it ship it. Like it or not, we live with (often
>unreasonable) deadlines. If your game is god-awful slow, that's bad.

If a game is anything like slow, that is bad. But terrible frame
rates are the norm, unless you upgrade.... as I keep on trying to say,
it never used to be like this, programmers worked with one set of
hardware, until they willed it to go faster... Pac Man would never
have come out going at 2 frames a second... but these days people have
to put up or shut up.

>But otherwise, your marketing department and your friendly neighborhood
>VP of Production are not likely to give you an extra six months on a
>project so you can get it 10% faster.

They might just do that, when they find that every product they make
is out paced by a competitor. Whether this situation will ever come
about, is one of the reasons for my posting.

> That may not sound very
>idealistic...but this is real life. Honing and crafting and obsessing
>over your pet routines is fine for a weekend passtime, but the reality
>is that there are WAY more jobs than people to fill them.
> As programmers, we are SWAMPED with tasks. We're smart people,
>working at full steam. We simply cannot afford ANY slowdown,

When the solution to a job means the addition of an entirely new
chapter to your novel, rather than the tweaking, or extension of an
old routine I suppose this is true. However, crafting is what the top
end of the game programming market is. To write a game with a strong
chance of commercial success you must have a great assembly skill,
even if you do only get to use it for one routine. Newbies are
systematically not told this. Also, surely you'd admit that the time
and care which your weekender could bestow on his program, is
something which we should at least try to approach in our commercial
lives. Otherwise it is 'sausage factory' all the way. You know the
backlash against 'Muck' burgers is starting, well bland coding cannot
exist forever either.

>Code reuse

I have *never* had *any* problem with code reuse in asm. Both
languages can be written out well for other people to read, both can
be written out terribly badly. People are put off learning Asm
because assemblers don't come with a huge library of routines, you
have to write them yourself, but once you have them, asm and c look
very similar to program, and one *is* faster.

>As for the "I'm tired of being forced to upgrade every year" thing...I

>simpathize, believe me.

If you did more than just simpathize, and actually worked *with*
machine coders to speed up your programs, then you could actually
help the situation... and don't say it! I know this costs money! I
believe that a company which shoulders some of the cost of code
optimisation, will be rewarded by the consumer. Imagine a world where
you don't have to buy a new computer, you just buy the best software.

>If your title runs well on a low-end
>machine, that's an indication that you are not "cutting edge".

This is desperately sad. I have yet to program a game which cannot
eat up all the speed available to me on today's computers. There is
*always* something you can add, whether it be hicolour, or a gamengine
tied to a single vertical retrace... or simply a few more sprites.

This alone justifies the need to program for lower spec machines...
if you can get your engine to work at say 1/30th with 256 palette on a
low end machine, the people with the high end ones, get twice the x
res, or twice the speed, or ^2 colours. Everyone is then happy.

>This
>holds even if your game is 100% pure uber-optimized assembly. Faster
>machines give you more clock cycles: use em.

Use them by all means, but don't waste a single one!

>Sorry for the rant, but you asked why ASM has fallen out of favor. ASM,
>in my experience, is certainly not dead. It is just not as universally
>appropriate as it used to be. That does not diminish its importance.

If what you said was entirely correct, of course it would diminish
its importance. If you really could write an OS in C, or as fast a
game, as a machine is able to run, then asm would be stuffed into
history.

You do seem to recognise the some of the importance of asm, but you
say you are speaking for a few people here. I am not so sure, from my
lurking, I have noticed an unhealthy disregard for asm in this group..
hence my attempts to redress the balance.

><\RANT>

I would write the same, but I feel like I have not yet got this out
of my system. :) Maybe we should argue about whether HTML has any
right to be called a 'language' instead?

James David Chapman.

[Russ Williams]

James David Chapman wrote in message <6dim1g$h6s$1...@heliodor.xara.net>...
>Matt Craighead <crai...@citilink.com> wrote:
[...]

>>1. DirectX/OpenGL
>
> Is not really the issue here,

Yes, it is.

>it may be a big thing in the world of windows,

You're an 3l337 DOS koder? Why am I not suprised?

>but assembly programmers have had full video control
>for years.

Get a fucking clue. Mode 13h / Mode X is completely pathetic.
Do you seriously think that asm offers any advantage for writing
to video RAM?

char *vga=(char *)0xa0000.

Real difficult C, that.

Try using asm to get 3d *acceleration* on, say, a Riva128.

---
Russ

[Russ Williams]

Jason Shankel wrote in message <34FD04...@seesig.for.address>...
[...]

>But otherwise, your marketing department and your friendly
>neighborhood VP of Production are not likely to give you an
>extra six months on a project so you can get it 10% faster.

With 6 extra months, I can think of better ways of getting at
least a 10% speed-up. Moore's law, for one ;)

(6 months would get an average 26% speedup, just by
waiting).

---
Russ

[Russ Williams]

James David Chapman wrote in message <6di8t3$9l6$1...@heliodor.xara.net>...

>
> The results of my earlier trolling of various threads on this
>group were predictable, if a little sad. However, it was not
>my intent to aggravate for the sake of it.

Hint: Starting a holy war tends to aggravate people...

> A few people have compared early pac man with the
>modern games we see today, and laughed. Yet I have no
>doubt the original pac man *was* as complex as the
>game engines of today.

Then you also have no clue.

>Just think about it... Were the programmers of then less
>clever than us?

Probably not.

>Why didn't they come up with DOOM? The answer is of
>course simple, they were packing features into machines
>which were too small, and running amazing routines on
>processors which were too slow.

So? Weak hardware kinda limits the complexity you can
achieve...

>They achieved the impossible and their code was like
>poetry, and like poetry, there had to be strict limits for it
>to work. But, how often do you find beautiful code like
>that today?

You might be suprised.

> Well you don't come across it very often.

Really? Who's code have you been looking at?

>Yet, hidden deep at the bottom of almost all the great games,
>you *will* find it...

Yes. That's because it takes talented programmers to make
a great game - and they tend to write very elegant code.

>the reason? You just can't run massive numbers of instructions
>through the processor every 1/30th sec.

Umm... so?

>You have to have a highly optimised machine language
>game engine.

Bzzzt. You clearly have no concept of profiling, otherwise
you'd realise just how little code most of the execution time
is spent in...

>The engine must fit into the processors cache, it must be
>interleaved, it must be written again and again, until it is
>the most efficient it can possibly be.

Some tiny bits of it, yes. What's your point?

> Now, I accept entirely that unoptimised ASM will produce
>code comparable with a C compiler,

Wrong. Unoptimised ASM will produce code up to an order
of magnitude worse than C. In fact, there's no limit to how
much slower ASM can be if coded by a moron...

>and that it can take longer to produce.

Yup. Much slower coding.

>However, at some stage, if you want to write a *game*,
>you are going to have to get your hands dirty. You are
>going to have to write machine level instructions.

Completely false. There is absolutely no need to use *any*
ASM in a modern game. 2d and 3d hardware acceleration
for the graphics, hardware mixing for the sound. It's perfectly
possible to write lovely fast games with *no* inner loops that
need optimising.

>As I have said, inner game loops *must* be machine code
>of the highest quality.

I don't think calling DrawPrimitive from asm will give you much
of a speed advantage...

>Support routines such as sound,

DSound.

>video,

DDraw, D3D, OpenGL, Glide.

>timer

timeSetEvent, QueryPerformanceCounter

>etc. all require low level hardware coding.

Only in worthless operating systems like DOS.

>Machine coding.

What, writing in hex?

>Any movement of pixel data must be done with assembly,

Really? I find hardware blitting works quite nicely...

>since most of the time in a gameloop is still spent doing
>just that... and as for maths, clearly there is no alternative.

What fucking planet are you on?

>Even efficient memory management must be done in
>assembly.

How do you justify having 'efficient' and 'memory management'
in the same sentence? No-one with more than half a brain-cell
mallocs in a tight loop in *any* language.

>So what else is there?

Hmmm. Everything?

>The menus.

The menus, file handling, calling any OS services, game logic
and AI. Everything that doesn't fit in the rendering module... and
much of what does.

>Okay, you can do them in C if you want, but if you try to code
>everything in C, only dropping out occasionally to a bit of
>inline, then when are you ever going to learn the skills
>required to write those optimised game loops?

In the 3 years you save on coding the rest of the game?

>I am unashamed to say that it took me 5 years to learn the
>m/c skills needed for a game engine,

I'd be very ashamed to say it took me 5 years to learn asm...

>and now I find that these skills are dying out, due to what I
>see as the inappropriate, over usage of C.

Ah well, maybe in about 20 years (judging by the learning rate
above), you'll figure out the hard way why we use C...

> You can never complain about Microsoft churning out
>average software like a sausage factory, without accepting
>that C must take some of the blame.

You know, they say a bad workman always blames his tools...

>C *is* easier to write. Assembly *does* take more time to
>write, and *is* harder to read. This is not a bad thing,

What are you smoking? Is it legal?

>and far more crucially, it is not, as Jason suggested, an
>anti-commercial thing.

Yes, it is. I can only think of 2 games companies that work in
pure ASM. Both produce crap games that take several years
to write.

>We can argue about Microsoft and a whether quality is their
>Achilles heal another time,

Oooh. Fun fun fun.

>but you must agree that where games are concerned,
>people buy quality,

Yup.

>and if games can be improved by machine code,

They can't.
More bugs and longer development != Higher quality.

>then the industry had better wake up and start hiring,
>or it may find that a different section of the unwashed will
>be driving the Ferraris.

Why? There are already a lot of talented assembly coders
in the industry. The difference between them and you is that
they realise that pure ASM is a WOMBAT (Waste Of Money,
Brains And Time).

> I had not intended a 'my language is better than yours'
>debate,

Too late.

>with all the tedious personal attacks and insinuations about
>programming style that USENET is famous for. I was simply
>reminding you that although C is dominant in the games
>market place today it need not always be that way.

It didn't used to be. People moved to C because it is easier
to program in (less time, less bugs) and almost all of the code
can settle for being 10% less than optimal with no noticable
speed loss.

>It seems people are confusing the work they do in their
>business programming with games design.

Almost all programming is done in C. There is a reason for
this.

> I am interested in why *you*, the *games* programmers are
>programming in what I, and the programmers of yesteryear
>would consider a mid level language, the only true benefit of
>which is portability, which clearly *is* a benefit, but one which
>comes at a price.

Yeah. About 10% speed loss compared to optimal assembler.
90% of the code takes 10% of the time. A 10% slowdown on
this code is ~1% of the total time. Is it worth spending 2 years
working 12 hour days to get that 1% back? No.

In fact, the 90-10 rule is closer to 99-1 these days.

>The price of making your code non-machine specific is
>speed.

Yup. A whole 10%.

>It will always be so. You cannot claim that C gives both,

Yes, I can. It does. You're assuming that non-trivial code can
be written in optimised asm. It can't. Not without 5-10 year
development cycles.

>there must be a compromise somewhere.
>

> For me, the compromise it too great. For you it isn't.
>I am interested to understand why.

I doubt you can. Most of us find using C to be an obvious way
of doing things. If you can't instantly see why writing and
debugging a million lines of asm is worse than 250k lines of
C, then there's probably very little chance of you seeing the
light.

---
Russ

[James David Chapman]

"Chris Lomont" <clo...@omni.cc.purdue.edu> wrote:

>James David Chapman wrote in message

>>[snip about ASM needed for games, and C being slower]

>With the release of the IA-64 chipset, the complexity of writing ASM
>code will be so high that a C compiler will produce faster code than
>probably every assembler programmer for large programs.

I don't think games are large programs. There is simply no time to
pass huge volumes of instructions through the processor in a game
engine, the system memory is too slow. (This is why codesprites came
and then quickly went).

>And it seems this trend will continue, since many other hardware
>manufacturers are looking at removing complexity out of the chip and
>into the compiler.

I chose to program the x86 partly for commercial reasons it has to
be said. However, this was underpinned by a love of the richness of
its instruction set. When the chip is totally RISCified, I will have
to consider moving on. From intel's point of view I kinda understand,
there is very little they can do to make the chip as a whole go any
faster, it is already pushed to breaking. It is a shame though, since
the instruction set is the only thing which differentiates the chip
from the competition, and of course, they are only passing the
bottleneck on to the poor memory developers, who will have to cope
with vast amounts of compiler code to shift about.

> Good hand assembly will become almost impossible.

No-one ever said programming in assembly was easy. :D

James.

[James David Chapman]

"Russ Williams" <ru...@algorithm.demon.co.uk> wrote:

Russ, Russ, Russ, I understand your need to try to insult, and maybe
you would prefer it if we were all talking on RUSSNET and your
thoughts were just beamed straight into our heads. However you cannot
touch me, the last thing I need is your approval, so please read what
I wrote in my last message again:

>it was not my intent to aggravate for the sake of it.

Accept this and move on. I am certainly not the first newcomer to a
newsgroup to skip the pleasantries and get down to the nitty-gritty,
the *real* differences. There is no time to mess about, you have to
grasp the nettle.

> I had not intended a 'my language is better than yours' debate

Accept this and work with it in this thread, everyone else has
managed to.

Sure C has benefits. Assembly does too. I honestly don't like
Windows and think that the market could benefit from a little
competition, and luckily the birth of the internet has allowed
alternative operating systems to co-exist. Not everyone is running a
PC and Win95, and the future could see even more diversity, and an asm
based OS is probably part of that diversity. Natural selection will
sort out the wheat from the chaff.

Hmmm.

Unfortunately the overly aggressive nature of your post has just
made be stop bothering to scan for and answer your points, some of
which I agreed with. But then again, debate was never your intention,
so go away, and grow up.

James David Chapman.

[Russ Williams]

James David Chapman wrote in message <6djlpe$5rd$1...@heliodor.xara.net>...

>"Chris Lomont" <clo...@omni.cc.purdue.edu> wrote:
>>James David Chapman wrote in message
>
>>>[snip about ASM needed for games, and C being slower]
>
>>With the release of the IA-64 chipset, the complexity of
>>writing ASM code will be so high that a C compiler will
>>produce faster code than probably every assembler
>>programmer for large programs.
>
> I don't think games are large programs.

Then you must be completely bereft of clues.

>There is simply no time to pass huge volumes of instructions
>through the processor in a game engine,

Wow, such naivete. That must be why modern games only have
16k of code, then...

>the system memory is too slow.

Yup. There's only about 100megs/s of usable bandwidth...

>(This is why codesprites came and then quickly went).

No, they were a completely different matter. Compiled sprites
died because:
i) No-one was willing to write an optimising sprite compiler
ii) Self-modifying code is bad
iii) One-shot code like this thrashes the instruction cache for
no worthwhile gain

>>And it seems this trend will continue, since many other
>>hardware manufacturers are looking at removing
>>complexity out of the chip and into the compiler.
>
> I chose to program the x86 partly for commercial reasons it
>has to be said. However, this was underpinned by a love of
>the richness of its instruction set. When the chip is totally
>RISCified, I will have to consider moving on.

What about the commercial reasons? Intel isn't going to let
go of the PC market, so 90+% of computers will still be
running Windows on Intel CPUs.

>From intel's point of view I kinda understand, there is very
>little they can do to make the chip as a whole go any faster,
>it is already pushed to breaking. It is a shame though, since
>the instruction set is the only thing which differentiates the chip
>from the competition, and of course, they are only passing the
>bottleneck on to the poor memory developers, who will have
>to cope with vast amounts of compiler code to shift about.

Compiler code is bigger than asm? Since when? The
differences are minimal, and only fuckwits like you insist
otherwise. A modern compiler does at least as well as a
competent asm coder. Like chess, optimisation is a small
set of simple rules that a computer can execute well, without
getting tired or bored or making mistakes (so long as the
rules are correct). A talented human can win by seeing 'the
big picture', but for simple by-the-book optimisation (squash
AGIs, pair instructions,...), the compiler will be just as good
in most cases.

>> Good hand assembly will become almost impossible.
>
> No-one ever said programming in assembly was easy. :D

It's not exactly difficult. More time consuming than anything
else. Optimising a few small routines can even be fun (like
logic puzzles or crosswords).

---
Russ

[James David Chapman]

Keith Elder <el...@cdsnet.ihatespam.net> wrote:

>James David Chapman wrote:
>>
>>
>> A few people have compared early pac man with the modern games we
>> see today, and laughed. Yet I have no doubt the original pac man

>> *was* as complex as the game engines of today. Just think about it...
>> Were the programmers of then less clever than us? Why didn't they

>> come up with DOOM? The answer is of course simple, they were packing
>> features into machines which were too small, and running amazing
>> routines on processors which were too slow.

>I agree wholeheartedly. I have a hard time trusting any programmer who
>has not paid their dues crafting an assembly game on a commodore 64, or
>apple ][, or any other 8 bit platform. My brother wrote and sold a very
>fast game he wrote for a VIC-20 that he wrote in machine language.
>Note: Not assembly, I mean _machine_language_!

Heh heh, when I am feeling particularly masochistic I have been
known to program 'the numbers' myself. [This will surprise no-one
here].

>Yes, we have tools that allow us to skip those tedious tasks, but I
>think in the process we have become disconnected from the intimacies of
>the hardware.

Phew, its good to hear that! When you listen to programmers today,
you start doubting yourself. (Then you go away and write 3
'impossible' things before breakfast, and tell yourself not to be so
silly).

>I think that many of the programmers from ten years ago were pulling
>performance out of the hardware they had in a way that no one is doing
>now.

Surely no-one in this news group can argue with this?

> Too often, in this very newsgroup, I have heard too many questions
>about code performance answered with a derisive "You only have a pentium
>100? Get a modern system, DUDE! That'll fix your problem."

I consider any system that is capable of running a TCP/IP stack a
system worth developing for, still 'modern' enough to take part in the
greatest development in computing history.

>Ah, well. Nostalgia is a potent drug ;)

Ooooh, now you have put your finger on it! I had two reasons for
posting here, firstly, I honestly thought it might do people a bit of
good to remember just how powerful m/c is. However, the second reason
was not so altruistic. I am interested to know whether m/c coding
*is* out of date... ..I have never met anyone who has the complete
answer to any problem, and so I must conclude that C must have a place
in games programming, and I want to know just where exactly it is.
The same goes for asm. Is it really destined to be consigned to a
little inline to get C programmers out of a tight spot? How can so
powerful a tool be left to rot?

James David Chapman.

[Gerry Quinn]

In article <6dir7a$l...@mozo.cc.purdue.edu>, "Chris Lomont" <clo...@omni.cc.purdue.edu> wrote:

>And it seems this trend will continue, since many other hardware
>manufacturers are looking at removing complexity out of the chip and

>into the compiler. Good hand assembly will become almost impossible.
>

Don't underestimate human ingenuity. Or overestimate compiler
quality.

- Gerry

===========================================================
ger...@indigo.ie (Gerry Quinn)
http://indigo.ie/~gerryq
Original puzzlers for PC, Amiga, and Java
===========================================================

[Thomas Womack]

James David Chapman <jc...@nospam.globalnet.co.uk.I.said.NO.spam> wrote:

: Jason Shankel <JasonS...@seesig.for.address> wrote:

: >James David Chapman wrote:
: >Those of us *game* *programmers* you identified in your original post
: >have to accept the overhead Windows imposes, at least those of us who
: >develop professionally for the PC.

: You might be forced to accept the Windows overhead, but you don't
: *have* to buy into the philosophy 100%.

: >The point is that even if all of the C code were magically transformed
: >so it executed instantaneously, you would only notice a 0.5% speedup.
: >It is simply not worth spending even a microsecond, much less the
: >additional MONTHS pure asm implies, to chase that kind of negligible
: >improvement. That time is better spend focusing on making your C code
: >readable, portable and maintainable and making your assembly fast.

: Hmmm, you're being a bit naughty here. Some people in this
: newsgroup are pretending that an *entire* game project can be coded in
: C, and still be the fastest it can possibly be. Even your mixture of
: C and asm does not address a fundamental issue I raised... where are
: the newbies in this group going to get their asm skills from if they
: program in C most of the time?

I am certainly the slowest programmer I know (deciding to go off and
learn maths instead might have something to do with this). I've been
working on a straightforward top-down scroller, for about three weeks
a year, for the last six years.

The first year, I wrote great reams of assembler for the ARM2
processor.

The next year, I ripped out most of the assembler and ran the game in
BASIC instead - and it worked much better and at not a discernably
slower speed.

The next year, I ported it to the PC with assembler for the sprite
plotting. And it was faster, for I was using a 33MHz 486 instead of an
8MHz ARM.

Two years later, I rewrote the sprite plotting in C and it went
faster because the C compiler scheduled the assembler correctly. And
the machine was a 90MHz Pentium instead of a 33MHz 486.

It's coming up to the time when I start looking at the game again. I
suspect, this time, there will be no sprite plotting routines at all,
and I will end up with a surface with tiles on it which I use bitblt
to plot to the screen. And it will be faster. Mostly because the
machine is a 233MHz P2 instead of a P90.

: This is *precisely* what I am talking about. The reason I mentioned

: coders of the past, was because they did care. They could not stop
: themselves from optimising because it was the only way to add new
: features to the game. It still is! Are you really saying that you
: could not use an extra 2Mb of data area for graphics or sound? I sure
: could.

No, I don't need another 2Mb of data area. All I'd use it for is
caching, and SmartDrive does that for me quite happily (or whatever
WinNT's disc cache is called; SmartDrive may have gone down with the
dodo).

If you like assembler, *please* go into the field of writing optimised
compilers. Donate your experience to the expert systems behind the
scenes. Marvel at the ability of software to consider 2^24 possible
orderings for a piece of code and produce the optimal one. Write
cache-friendly library routines; speeding up MSVC's memcopy improves
almost every piece of code around. Write graphics libraries with
properly-scheduled geometry. Write an FFT routine which is aware of
the cache layout. But don't waste your time persuading people to write
games in a slow and laborious way.

Tom

[Kalrithian]

James David Chapman wrote in message <6djk4e$4rl$1...@heliodor.xara.net>...
:Jason Shankel <JasonS...@seesig.for.address> wrote:
<snip>
:>The point is that even if all of the C code were magically transformed

:>so it executed instantaneously, you would only notice a 0.5% speedup.
:>It is simply not worth spending even a microsecond, much less the
:>additional MONTHS pure asm implies, to chase that kind of negligible
:>improvement. That time is better spend focusing on making your C code
:>readable, portable and maintainable and making your assembly fast.
:
:
: Hmmm, you're being a bit naughty here. Some people in this
:newsgroup are pretending that an *entire* game project can be coded in
:C, and still be the fastest it can possibly be. Even your mixture of
:C and asm does not address a fundamental issue I raised... where are
:the newbies in this group going to get their asm skills from if they
:program in C most of the time?

:
IME, assembly language is used for two major things: optimized hardware
access and tight inner loops. DirectX solves the first problem, and better
C++ compilers have basically made the second almost a non-issue. Twelve
years ago, Borland and Microsoft sold compilers with crap optimizers; these
basically inserted pre-built blocks of code for every defined C construct.
Then, sometime in the late '80's, Watcom came along with their compilers,
and it totally blew away Borland and MS. Since then, Microsoft has greatly
improved their compilers; VC++ 5 is at least as good as Watcom 10.6, IMHO.
Anyway, the point is that hand-generated assembly has to be pretty good to
beat out compilers nowadays, which makes the benefits of assembly that much
less evident.

As for newbies learning assembly, I think that they should stick with C or
C++ until they get good at making games. I've seen all too many newbies
waste weeks or months writing assembly code that would be simpler and almost
as fast in C/C++. Compiler-generated code is going to knock the pants off of
newbie assembly code, anyway.

:
:>> >1. DirectX/OpenGL

:>>
:>> Is not really the issue here, it may be a big thing in the world of
:>> windows, but assembly programmers have had full video control for
:>> years.
:>>
:
:>You cannot get such access to 3d hardware in any other way. You simply
:>do not have the option of register programming these cards, you must use
:>an API.
:
:
: Hardware manufacturers will soon learn not to keep their internal
:specs to themselves.

:
Excuse me for a moment. (HA HA HA HA HA HA HA! Ahem.) What's going to make
that happen? Those guys are out to make money, and by publishing their
specs, they give their competitors their trade secrets. Quite frankly, they
could care less if Joe Coder wants to write fast code for DOS or Linux.
Windows makes money; it's that simple.

:>Executable size, for example, is now MUCH less of an issue than it was

:>even a few years ago. When modern games require 16-32 megs to run, a 3
:>meg executable size is not even considered a factor.
:
:IT SHOULD BE.

:
Not when the end user has megs and megs of cheap, free disk space.

: This is *precisely* what I am talking about. The reason I mentioned

:coders of the past, was because they did care. They could not stop
:themselves from optimising because it was the only way to add new
:features to the game. It still is! Are you really saying that you
:could not use an extra 2Mb of data area for graphics or sound? I sure
:could.

:
This is an interesting phenomenon. As memory and disk space become cheaper,
there is less and less push to squeeze stuff into them. Take Windows 95, for
example. I think that most of those features could have been implemented in
much less memory and disk space. Case in point: the startup and shutdown
splash screens are stored on disk as uncompressed BMP files.

: I can't think what doesn't have to be rip roaring fast in a game.

:Init routines have been mentioned, menus, maybe, if they are not
:displayed by the game engine itself, everything else is inside some
:kind of loop, so you'd better be careful.

:
Disk access is what slows down init routines, and assembly won't help you
there. Better design will, though.

:
: Surely this attitude you have: "It doesn't matter how large the exe

:is/almost all the code is non-time crucial", is linked to the reason
:why people have to upgrade their computers every year? Surely you can
:see that? :)
:
:
: And surely you can see that, from my point of view, the number of
:routines which are 'allowed' to be large and slow is increasing every
:day! Never in a million years would *anyone* have agreed that low
:level operating system functions should be done in anything other than
:machine specific, machine code... and yet now it is accepted and
:widespread. Doesn't mean its right.

:
No, but when you're trying to write an OS and get it on shelves as quickly
as possible, assembly language is not the best way to go about it. As
mentioned before, good compilers can produce code that's better than the
average coder's assembly.

:
: You can't believe how frustrated it makes me, to find, games,

:traditionally accepted as pushing *the machine* to the limits, (rather
:than the 'cutting edge', whatever that is), have now been lumped into
:"Heck Boss we can do it in C, and get the customer to pay for the
:speed increase through hardware".
:
: No. It is about time that the developers started to shoulder some
:of the (very real) costs associated with speed, like they used to. My
:point is, that a developer who does this *will* find they have a
:commercial advantage, since people are getting sick of upgrading,
:*very* expensive machines.

:
Face the facts: it's less expensive for developers to do a game that takes
powerful hardware than to take twice as long and do it all in assembly.
People will play games, even if it means upgrading every few months. For the
developer, it's less effort, and it's cheaper. It also keeps the money
rolling in for computer vendors, so they like it too.

: I have *never* had *any* problem with code reuse in asm. Both

:languages can be written out well for other people to read, both can
:be written out terribly badly. People are put off learning Asm
:because assemblers don't come with a huge library of routines, you
:have to write them yourself, but once you have them, asm and c look
:very similar to program, and one *is* faster.

:
C++ code originally written on a 486 can be recompiled for a Pentium or
Pentium Pro. You can't do this easily with assembly.

:>If your title runs well on a low-end

:>machine, that's an indication that you are not "cutting edge".
:
: This is desperately sad. I have yet to program a game which cannot
:eat up all the speed available to me on today's computers. There is
:*always* something you can add, whether it be hicolour, or a gamengine
:tied to a single vertical retrace... or simply a few more sprites.

:
Hey, that's life. Big Corporation is out to make as much money as possible,
and they can't do that unless they do a cutting-edge title.

:
: This alone justifies the need to program for lower spec machines...

:if you can get your engine to work at say 1/30th with 256 palette on a
:low end machine, the people with the high end ones, get twice the x
:res, or twice the speed, or ^2 colours. Everyone is then happy.

:
Not the guy who just spent a few thousand dollars on a high-end machine.

Kalrithian

[Sean Timarco Baggaley]

In article <matthewpE...@netcom.com>, Matt Pritchard
<matt...@netcom.com> writes

[...]

>: 5. C code is more readable, less buggy on average
>Disagree - depends on the programmer

What? You seriously find x86 assembly easier to read than C? Give me
Motorola 680x0 -- or even Zilog Z80 -- any day. At least they didn't go
out of their way to make life harder for the programmer.

C has the advantage of actually making sense when you read it. Even the
semi-colon makes sense -- it is, after all, merely dividing the elements
of a list.

Where assembly excels is in speeding up critical code when no
alternative exists: the central texture mapping loop of a software
renderer for instance.

But there comes a point when further optimisation is pointless: if your
cut-scene FMV rendering code is already running at the maximum frame-
rate of the animation, there's nothing to be gained in making the code
any faster. If you can achieve that frame-rate in 100% C (and that has
been done), there's simply no reason for using assembly aside from ego.

3D graphics engines are also approaching the point when assembly-coded
optimisations are redundant: hardware acceleration is taking its place.
(And with 1Ghz CPUs just around the corner you may yet see Quake clones
being written in Visual BASIC...)

--
Sean Timarco Baggaley

<mailto:stim...@cix.co.uk>

E&OE

[Sean Timarco Baggaley]

In article <34FCFC82...@mindspring.com>, Pat Smith
<quan...@mindspring.com> writes, in reply to...

>> James David Chapman.

[...]

>I'm glad to know someone else who realizes that almost all the
>programers have about gone to shit. :)

Rose-tinted spectacles are notorious for having this effect.

>Seriously, I perfered the old days where you wrote a program that
>required your skills and knowedge for performance, now its all hardware
>based. I thought the hardware was supose to open doors, not cover
>sloppyness.

Really? Ever played some of those 8-bit games?

I remember a certain Number 1 platform game released for the Sinclair
Spectrum ("Jet Set Willy") which contained a major bug thinly disguised
as a 'feature'. Entering a specific location caused your character to be
killed outright if you entered a second (specific) location. Even if you
had three lives left, it'd be Game Over time.

It was a bug. Plain and simple. In *released* code. In a game that ran
on a 48Kb, Z80-based computer (including all the data.)

And there were plenty of other buggy products out there written in 100%
"pure ASM". Anyone remember 'Frontier'?

And who can forget those wonderfully unreliable 'fast-loaders' that used
to reset the machine at the slightest provocation? ("Novaload" [C64] and
that thing MikroGen used to use [Spectrum] spring rapidly to mind.)

--
Sean "What the hell happened to Rob Northen, anyway?" Baggaley

<mailto:stim...@cix.co.uk>

E&OE

[Thomas Womack]

Kalrithian <eem...@txdirect.net> wrote:

: This is an interesting phenomenon. As memory and disk space become cheaper,

: there is less and less push to squeeze stuff into them. Take Windows 95, for
: example. I think that most of those features could have been implemented in
: much less memory and disk space. Case in point: the startup and shutdown
: splash screens are stored on disk as uncompressed BMP files.

Take Quake ... sets of textures stored in each .BSP file. Take Quake
][ - everything done in uncompressed .PCX or .TGA files. Note that a
large number of BBC Micro games were not much reduced in size by
something like PKZIP, due to habits like storing a map with 32 sorts
of tile in 5 bits per tile and decompressing at runtime.

Would an annotated disassembly of Citadel still amaze people after all
these years?

But CDs are cheap, and the cost of hard disc space is between three
and five pence a megabyte. Quake ][ is still really big, though; I
can't quite understand why the textures couldn't be stored on disc in
.GIF format.

Tom

[Sean Timarco Baggaley]

In article <6djk4e$4rl$1...@heliodor.xara.net>, James David Chapman
<jc...@nospam.globalnet.co.uk.I.said.NO.spam> writes

[...]

> You can't believe how frustrated it makes me, to find, games,
>traditionally accepted as pushing *the machine* to the limits, (rather
>than the 'cutting edge', whatever that is), have now been lumped into
>"Heck Boss we can do it in C, and get the customer to pay for the
>speed increase through hardware".

You can't believe how frustrated it makes me to find games programmers
who insist on wasting time speeding up non-critical game areas at the
expense of games design. Been there. Seen it. Done it. Thankless task
and nobody (apart from other [good] programmers) will *ever* know -- or
care.

[...]

> You do seem to recognise the some of the importance of asm, but you
>say you are speaking for a few people here. I am not so sure, from my
>lurking, I have noticed an unhealthy disregard for asm in this group..
>hence my attempts to redress the balance.

Pro-technology people are forever whining about how 100% pure ASM (or
whatever) is so bloody important, but it's bullshit. It's the *GAME*
that's important. Code quality is secondary, since without a good game
for the coders to actually work on, all that effort it pointless.

If I'm faced with a choice between spending a month optimising for a
<10% increase or spending that same month getting the *gameplay* right,
I'd choose the latter every time.

Games programming is about programming *games*, not merely 'elegant' or
'pedal to the metal' code. Code is important, but having a game *worth*
coding is far more important.

[...]

> I would write the same, but I feel like I have not yet got this out
>of my system. :) Maybe we should argue about whether HTML has any
>right to be called a 'language' instead?

It's a 'mark-up language' -- that's what the 'M' and 'L' in 'HTML' stand
for. Just because it ain't used for programming doesn't make it any less
a language.

[Russ Williams]

James David Chapman wrote in message <6djk4e$4rl$1...@heliodor.xara.net>...
>Jason Shankel <JasonS...@seesig.for.address> wrote:

[...]

> You might be forced to accept the Windows overhead, but
> you don't *have* to buy into the philosophy 100%.

Maybe we buy into the philosophy because we believe it's
correct.

>>The point is that even if all of the C code were magically
>>transformed so it executed instantaneously, you would
>>only notice a 0.5% speedup. It is simply not worth spending
>>even a microsecond, much less the additional MONTHS
>>pure asm implies, to chase that kind of negligible
>>improvement. That time is better spend focusing on
>>making your C code readable, portable and maintainable
>>and making your assembly fast.
>
> Hmmm, you're being a bit naughty here.

By being logical?

>Some people in this newsgroup are pretending that an
>*entire* game project can be coded in C, and still be the
>fastest it can possibly be.

That's not a pretence. That's a fact. Pure asm projects are
no more (and often less) optimised than C. If a game is
hardware limited, then saving half a percent off of the logic
time is irrelevant, because you still need to sync it.

>Even your mixture of C and asm does not address a
>fundamental issue I raised... where are the newbies in
>this group going to get their asm skills from if they
>program in C most of the time?

From the time they save on writing everything else, by
reading docs, books and disassembly of the compiler
output. The latter is how I learnt R3000 asm. Docs such
as Intel's x86 Optimisation Manual and Pentium specs
and Agner Fog's optimisation details are sufficient to
learn the optimisation tricks. Things like VTune which show
you why a particular instruction sequence is stalling are
invaluable.

[...]

>>You cannot get such access to 3d hardware in any other
>>way. You simply do not have the option of register
>>programming these cards, you must use an API.
>
> Hardware manufacturers will soon learn not to keep their
>internal specs to themselves.

Why? All the major development houses are happy to use
C and simple APIs instead of register-level hardware
hacking. A few hard-core demo coders who insist on having
hardware specs won't make the slightest bit of difference.
After all, most of them will just spend so long optimising and
re-optimising their pure-asm code that they never release
anything.

[...]

>>The sentiment, I think, myself and others are trying to
>>convey is not that there is no regard for assembly
>>programming, but rather that advances in technology
>>have shifted our priorities.
>
> I appreciate *your* position, I am here to remind you not
>to go to far in this shift, or you will see all the worst things
>about C take over the industry. Yes, there *are* bad things
>about C!

Suprisingly few, to be honest. It's a clean, simple language
with almost everything implemented as RTL. C is over 20
years old and has never been more popular. Why? Because
it *works*. It does the job better than anything else that's
been offered.

>>Executable size, for example, is now MUCH less of an issue
>>than it was even a few years ago. When modern games
>>require 16-32 megs to run, a 3 meg executable size is not
>>even considered a factor.
>
>IT SHOULD BE.

WHY? Concentrate on the things that matter. Executable size
would be about #279 on that list. People are buying machines
with 32-64 mb of RAM and several gigs of HDD space.

> This is *precisely* what I am talking about. The reason I
>mentioned coders of the past, was because they did care.
>They could not stop themselves from optimising because
>it was the only way to add new features to the game.
>It still is!

No, it isn't.

>Are you really saying that you could not use an extra 2Mb of
>data area for graphics or sound? I sure could.

It's irrelevant. Windows is a *virtual memory* OS. It doesn't
matter how much RAM is allocated (so long as it's less than
the swapfile size), only how often it is paged.

>>Execution speed for outer loop functions is less of a
>>critical issue.
>
>I am happy to agree with this again.

So why argue for 100% asm?

>>But high level languages provide adequate speed for
>>anything which doesn't have to be rip-roaring fast.
>
> I can't think

(Naaah. Too obvious.)

>what doesn't have to be rip roaring fast in a game.

Almost all of it.

>Init routines have been mentioned, menus, maybe, if they
>are not displayed by the game engine itself, everything else
>is inside some kind of loop, so you'd better be careful.

So? That's worth spending several months/years on a 10%
improvement for?

> Surely this attitude you have: "It doesn't matter how large
>the exe is/almost all the code is non-time crucial", is linked
>to the reason why people have to upgrade their computers
>every year?

Of course.

>Surely you can see that? :)

Yup. People upgrade every 12-18 months. That means that
we're having to hit a moving target in terms of machine specs.
In effect, most PC games are ported at least once, due to
changing hardware (develop for a Pentium, then find out that
everyone's got a P-II). Asm is simply too inflexible for that - by
the time you'd re-optimised the 486 code for a Pentium,
people would own P-IIs.

> And surely you can see that, from my point of view, the
>number of routines which are 'allowed' to be large and
>slow is increasing every day!

Yes. What's wrong with that? (Especially where slow is
less than 10% off optimal).

>Never in a million years would *anyone* have agreed that
>low level operating system functions should be done in
>anything other than machine specific, machine code...

I guess you'd better tell that to those ignorant morons
Brian Kernighan and Dennis Ritchie. And tell them Unix
sucks, while you're at it.

>and yet now it is accepted and widespread. Doesn't
>mean its right.

C is a systems programming language. What would you
expect an OS to be written in?

> You can't believe how frustrated it makes me, to find,
>games, traditionally accepted as pushing *the machine*
>to the limits,

Yup, they do.

>(rather than the 'cutting edge', whatever that is), have now
>been lumped into "Heck Boss we can do it in C, and get the
>customer to pay for the speed increase through hardware".
>
> No. It is about time that the developers started to shoulder
>some of the (very real) costs associated with speed, like
>they used to.

Should we also design the hardware that we use? After all,
the early coin-op developers did just that...

>My point is, that a developer who does this *will* find they
>have a commercial advantage,

No, they won't. That's the whole fucking point. Pure asm
is a commercial disadvantage, since it costs more to
develop and more to debug. Putting an inferior game onto
the market 2 years late can't be made up for by having
really neat asm. You chide us for being ruled by market
forces and then in the next paragraph claim that the market
wants us to do things differently? Try proofreading your
posts...

>since people are getting sick of upgrading, *very*
>expensive machines.

So what else is new? People bitch about having to buy a
new console every 2 years - they still do it. Besides, the
people with the money to spend $200 on games on a
whim are the ones that can afford new hardware. That's
why we don't support 486s - there's no money in it. The
people who buy games buy new hardware, and they want
the games to show off that shiny new 3dfx card...

>>Among the new priorities:
>>Portability. Windows may dominate the desktop, but the
>>console landscape changes radically every few years.
>>Sure, your engine code will probably have to change, but
>>it would be nice if you could move your simulator from the
>>PC to a console without TOO much pain.
>
> There comes a time when you have to just sit down and
>say, "this game is designed for this machine",

Followed very shortly by your boss saying either "Well, we'd
like you to do a PSX port..." or "You're fired! I told you we
wanted a PSX port of it!"

>your customers are clearly paying for the portability of your
>code as well. You better hope they don't wise up.

They'd pay a damn sight more if the code wasn't portable.
It would quite simply increase development costs. Instead
of splitting the costs between PSX, N64, PC and Mac, you
would have 4 lots of development. At, say, $2m for a
typical game (G.O.D's figures), that would be an extra $6m
to recoup in profits. $100 games, anyone?

>> Assembler code you so lovingly craft at the beginning of
>>a project is likely to be sub-optimal on the hardware which
>>exists when you ship.
>
>I really don't find this. Routines just run faster and faster.

Then it's not optimal...

[...]

>>But otherwise, your marketing department and your friendly
>>neighborhood VP of Production are not likely to give you an
>>extra six months on a project so you can get it 10% faster.
>
> They might just do that,

Not in this universe.

>when they find that every product they make is out paced by
>a competitor.

So what? Ship 6 months late and you're just another clone.
Your competitor is also half way to completing their *next*
game.

>Whether this situation will ever come about, is one of the
>reasons for my posting.

It won't. Pure asm has died for good reason.

>> That may not sound very idealistic...but this is real life.
>>Honing and crafting and obsessing over your pet routines
>>is fine for a weekend passtime, but the reality is that there
>>are WAY more jobs than people to fill them.
>>As programmers, we are SWAMPED with tasks. We're
>>smart people, working at full steam. We simply cannot
>>afford ANY slowdown,
>
> When the solution to a job means the addition of an
>entirely new chapter to your novel, rather than the tweaking,
>or extension of an old routine I suppose this is true.
>However, crafting is what the top end of the game
>programming market is.

But no obsessing over <10% speed-up. There are better
things to hone, like playability.

>To write a game with a strong chance of commercial
>success you must have a great assembly skill, even if
>you do only get to use it for one routine.

And our survey says... Uh uh.
Nope. Simply not true.

>Newbies are systematically not told this.

Because it's not true?

[...]

>>Code reuse
>
> I have *never* had *any* problem with code reuse in asm.

So you consider 386 optimised asm to be useful, then?

>Both languages can be written out well for other people to
>read,

But that screws performance in asm...

>both can be written out terribly badly. People are put off
>learning Asm because assemblers don't come with a
>huge library of routines, you have to write them yourself,
>but once you have them, asm and c look very similar to
>program, and one *is* faster.

Yup. C, in most cases. Asm != Fast.

>>As for the "I'm tired of being forced to upgrade every year"
>>thing...I simpathize, believe me.
>
> If you did more than just simpathize, and actually worked
>*with* machine coders to speed up your programs, then
>you could actually help the situation...

You seem to be missing a fundamental point - many of us
*are* at least proficient in x86 assembly. We *choose* to
use C.

>and don't say it! I know this costs money! I believe that a
>company which shoulders some of the cost of code
>optimisation, will be rewarded by the consumer.

Such optimism.

>Imagine a world where you don't have to buy a new
>computer, you just buy the best software.

Hmmm. Not as good as the John Lennon version...

>>If your title runs well on a low-end machine, that's an
>>indication that you are not "cutting edge".
>
> This is desperately sad. I have yet to program a game
>which cannot eat up all the speed available to me on
>today's computers. There is *always* something you can
>add, whether it be hicolour, or a gamengine tied to a single
>vertical retrace... or simply a few more sprites.
>
> This alone justifies the need to program for lower spec
>machines...
>if you can get your engine to work at say 1/30th with 256
>palette on a low end machine, the people with the high
>end ones, get twice the x res, or twice the speed, or ^2
>colours. Everyone is then happy.

Except the poor bastards who have to write twice the
amount of graphics code and do twice as many images...

[...]

>>Sorry for the rant, but you asked why ASM has fallen out
>>of favor. ASM, in my experience, is certainly not dead.
>>It is just not as universally appropriate as it used to be.
>>That does not diminish its importance.
>
> If what you said was entirely correct, of course it would
>diminish its importance. If you really could write an OS in
>C, or as fast a game, as a machine is able to run, then
>asm would be stuffed into history.

It already is, basically, and for the reasons you give.

> You do seem to recognise the some of the importance
>of asm, but you say you are speaking for a few people
>here. I am not so sure, from my lurking, I have noticed an
>unhealthy disregard for asm in this group.. hence my
>attempts to redress the balance.

What is unhealthy is the number of 'speed at all costs'
morons who can't see beyond the next line of code.
Everyone else has taken the hint and will happily trade
a few % to halve development time, or a couple of % of
CPU time to get virtual memory, disk caches and
standardised (accelerated) hardware interfaces.

---
Russ

[Brandon Reinhart]

James David Chapman wrote:

> Hmmm, you're being a bit naughty here. Some people in this
> newsgroup are pretending that an *entire* game project can be coded in
> C, and still be the fastest it can possibly be. Even your mixture of
> C and asm does not address a fundamental issue I raised... where are
> the newbies in this group going to get their asm skills from if they
> program in C most of the time?

What neither party has stressed in this discussion is that true
speed doesn't happen at the implementation level. It happens
at the algorithmic level. If the algorithm or method by which
you are solving your problem isn't fast then it doesn't really
matter how much optimization in assembly you end up doing.
At best, you might see a 25%-50% performance increase by
using assembly over C, assuming a non-optimized compiler and
significantly smaller increases assuming a well optimized
compiler.
On the other hand, if you are using a well designed or
well thought out algorithm, you will often realize speed
increases on the level of orders of magnitude (assuming you
are comparing with other or previous design choices). Even
simple things like changing loop positions or orders of
execution (on the algorithmic level) can have significant
impacts.
That's really just academic, however, if we assume that we
are optimizing a bit some already chosen algorithm.
There just isn't any reason to use assembly if your program
is already fast enough. If your game runs how you want it to
on the platform you are targetting, than why rewrite a part
of it in assembly? Don't optimize until you need to.
In addition, use of a good compiler (like MSVC) can generate
code that is much tighter and faster than any assmebly
most programmers would be able to write by hand. (Naturally,
there are special cases, most compiler specific, when a
compiler generates code that is significantly slower than
what you intend. Know your compiler.)
Assembly optimization on today's high end (tommorrow's low end)
machines is made even more difficult by things like
branch prediction and out of order execution. As processors
become more advanced in the realm of "on the fly" optimization,
the programmer is freed from having to optimize at the low level.
I think that the answer to the question "Should I write part
of my game in assembly?" depends on the target machine,
the target frame rate, and the existing code behavior. If you
are meeting your goals now, don't optimize in assembly.
Spend that time working on a new feature or cleaning up bugs.
When you've added some new feature (say a totally amazing
particle effect) that starts to stress the framerate, THEN
profile and optimize. Find out where the stress is being
generated and explore how that part of the code can be
made more efficient. You might be able to make your code
*significantly* faster without even looking at assembly.
IF you have exhausted all algorithmic solutions you can think
of and IF you compiler is generating the best solution you
think it can put out and IF you can't think of any other way
to do it THEN explore optimization in assembly.
ON THE OTHER HAND...that doesn't mean you shouldn't LEARN
assembly. Just because it may be unnecessary to ever use
it in your games, that doesn't mean it isn't necessary to
understand what is going on. Knowing what a certain op
code means might just clue you in as to why your program is
mysteriously dropping cycles, and someday you might be
called on to use assembly to optimize a part of your program.
The questions of whether you SHOULD USE something and whether
you SHOULD KNOW something are entirely different. You
SHOULD ALWAYS KNOW what your program is doing at any point
in time...at least make the effort to discover what it is
doing. That way, when it comes time to ask yourself whether
you SHOULD USE, say, assembly to optimize you know the
answer (or at the least the pros and cons).
I believe that assembly will become a less and less important
tool in the game programmer's box. Processors and compilers
already do a large amount of low level optimization for the
code author...and rightly so. The code author should be
busy with algorithmic solutions (no processor or compiler,
no matter how smart, can make a slow algorithm fast...at best
you get a slow fast algorithm). On the other hand, I believe
that at the same time assembly is becoming less of an optimization
tool it is becoming more important to understand. Often,
understanding of the machine's low level behavior can allow for
more intelligent high level code structuring. Pentium II
behavior is a very complex thing...and the more complex a thing
is, the more hidden ways it can affect your code.

> >Boss: "How long will that main menu routine take?"
> >Programmer: "Two days, or two hours, if I use C."
> >Boss: "Use C."
> >Programmer: "But it'll be 10-20% slower!"
> >Boss: "It's a menu routine, I don't give a frag."

The programmer in this situation should have never considered
using assembly. (Or s/he might have considered it and quickly
discarded the idea.) Assembly is the last resort to any
optimization process.

> IT SHOULD BE.
>
> This is *precisely* what I am talking about. The reason I mentioned
> coders of the past, was because they did care. They could not stop
> themselves from optimising because it was the only way to add new
> features to the game. It still is! Are you really saying that you
> could not use an extra 2Mb of data area for graphics or sound? I sure
> could.

It should be and for any *good* game programmer it is. I don't
have any URLs, but I know there are some good articles on
code size control out there on the web. Making a code save of
2 Mb on anything is a rough job, however and can take a long
time. Code size optimization can be done, somewhat, on an
algorithmic level and any algorithmic optimization should be
(obviously) done at the beginning of the design process.
Conversely, if you are talking about the core of code
size optimization (getting down into the nitty gritty to save
a few kilobytes or even a few bytes), then you should probably look
at doing it last.

> I can't think what doesn't have to be rip roaring fast in a game.
> Init routines have been mentioned, menus, maybe, if they are not
> displayed by the game engine itself, everything else is inside some
> kind of loop, so you'd better be careful.

Then maybe you need to take a step back. Rip roaring fast
is relative. It IS entirely possible to write a good, fast game
entirely in a high-level language. The question is: Does the
speed you achieve using the high-level language meet your goals?
What speed increases could be gained using assembly optimization?
You aren't going to be achieving orders of magnitude speed
increases using assembly optimization...optimizing your overall
design, however, might just.

> And surely you can see that, from my point of view, the number of
> routines which are 'allowed' to be large and slow is increasing every
> day! Never in a million years would *anyone* have agreed that low
> level operating system functions should be done in anything other than
> machine specific, machine code... and yet now it is accepted and
> widespread. Doesn't mean its right.

Doesn't mean its wrong, either. I guess my point is:
"Fast enough is fast enough." Why optimize when you have
achieved your speed requirements? If you've got a game with,
say, 45 FPS (average) with DirectInput and optimizing (heh, rewriting)
an input routine in assembly would (by your guestimation)
give you 47 FPS (average) is it really necessary to optimize?
Remember, ultimately the question of C vs ASM is relative.
The answer varies from situation to situation.

> You can't believe how frustrated it makes me, to find, games,
> traditionally accepted as pushing *the machine* to the limits, (rather
> than the 'cutting edge', whatever that is), have now been lumped into
> "Heck Boss we can do it in C, and get the customer to pay for the
> speed increase through hardware".

I don't think developers are thinking this way, and I don't
agree, but that'll have to go into another post.

> When the solution to a job means the addition of an entirely new
> chapter to your novel, rather than the tweaking, or extension of an
> old routine I suppose this is true. However, crafting is what the top
> end of the game programming market is. To write a game with a strong
> chance of commercial success you must have a great assembly skill,
> even if you do only get to use it for one routine. Newbies are
> systematically not told this. Also, surely you'd admit that the time
> and care which your weekender could bestow on his program, is
> something which we should at least try to approach in our commercial
> lives. Otherwise it is 'sausage factory' all the way. You know the
> backlash against 'Muck' burgers is starting, well bland coding cannot
> exist forever either.

You are utterly wrong, here. Read everything that I write
above. I constantly hear this and I'm constantly annoyed by
it. To say that assembly is necessary in EVERY game ALL the
time is a gross generalization and is, simply said, WRONG.
Newbies shouldn't be told this! To be trapped in the mindset
of "I must do things this way." is the first step to the road
of obsolecense <sp>. Assmebly-less coding doesn't mean
bland coding. Lack of creativity, lack of ability to think
in different mindsets, and inability to approach an issue from
someone else's perspective make bland code.

> This is desperately sad. I have yet to program a game which cannot
> eat up all the speed available to me on today's computers. There is
> *always* something you can add, whether it be hicolour, or a gamengine
> tied to a single vertical retrace... or simply a few more sprites.

Anyone can write code that eats up cycles. The skill lies in
finding out why the code eats up cycles and what the best
way of recovering lost time is. Assembly isn't always (and now
is rarely) the solution to the problem.

Brandon Reinhart

--
"Nothing in the world can take the place of persistence.
Talent will not; nothing is more common than unsuccessful men
with talent. Genius will not; unrewarded it's almost a proverb.
Education will not; the world is filled with educated derelicts.
Persistence and determination alone are omnipotent."
-- Calvin Coolidge

[Mirkurius]

>>They achieved the impossible and their code was like
>>poetry, and like poetry, there had to be strict limits for it
>>to work. But, how often do you find beautiful code like
>>that today?
>
>You might be suprised.
>
>> Well you don't come across it very often.
>
>Really? Who's code have you been looking at?
>
>>Yet, hidden deep at the bottom of almost all the great games,
>>you *will* find it...
>
>Yes. That's because it takes talented programmers to make
>a great game - and they tend to write very elegant code.

Actually, a lot of modern code is very ugly. Take a look at the Descent
source code that was recently released, and thats considered an excellent
modern game that broke new ground. The shear amount of algorithmic logic
needed to code most games today combined iwht the whips wielded by
publishers and venture capitalists leaves little time for making the code
pretty. Obviously, though, it is the mark of a good programmer to write as
elegently as possible.
Also, if you look at the code for very early games, especially consoles like
the Atari 2600, it is very amazing what they managed to do in such little
space. VERY elegant. coders dont write like that any more because they don't
have to. That was mostly a memory issue, which is becoming less and less
important. Its kinda sad, but so is the decline of the horse and buggy....

>>However, at some stage, if you want to write a *game*,
>>you are going to have to get your hands dirty. You are
>>going to have to write machine level instructions.
>
>Completely false. There is absolutely no need to use *any*
>ASM in a modern game. 2d and 3d hardware acceleration
>for the graphics, hardware mixing for the sound. It's perfectly
>possible to write lovely fast games with *no* inner loops that
>need optimising.

Bravo, we finally have good tools, API's and fast machines.

>>Any movement of pixel data must be done with assembly,
>
>Really? I find hardware blitting works quite nicely...

I think it is safe to say that this poster is not taking hardware
acceleration into account at all, and his argument is solely based on
software renderers.

>I can only think of 2 games companies that work in
>pure ASM. Both produce crap games that take several years
>to write.

Care to share what companies these are? Just curious....

Mirkurius

[Louis Tremblay]

Perhaps we need a little example here. Our own project here does something
like a QuickTime VR engine with some nice extras( like video sprites, etc ).
We _could_ have written it in ASM, but we did it in C.

Now for the number. The inner loop of the engine is 3 lines in C. It
takes(in theory) 8 cylcles to execute them. Why would I want to use ASM to
code those? Those 3 lines are executed 99% of the time and writing them in
ASM would not have made those faster( I've read the asm output of my
compiler. It is Watcom 11.0 by the way and have the reputation of doing very
fast code( for C )).

I'm not saying that ASM is useless( hell, I've written(in asm) too much
demos for the amiga scene in 1987-1990 to say that ). What I say is that for
most project, writting the code in C is less costly in term of
time/effeciency.

--
Louis Tremblay
lo...@zaq.com
ZAQ Technologies

[Robert Blum]

Louis Tremblay wrote:
>Perhaps we need a little example here. Our own project here does something
>like a QuickTime VR engine with some nice extras( like video sprites,
etc ).
>We _could_ have written it in ASM, but we did it in C.

Anybody *not* doing QTVR here? You're the fifth or so I see in a month. Hope
I'll ship first :-)

Bye,
Robert

[that's .com in disguise Christer Ericson]

On Wed, 4 Mar 1998 01:07:52 -0500, "Chris Lomont" <clo...@omni.cc.purdue.edu>
wrote:
>[...]

>So I believe assembly will die out as more chips take this path. This
>is one reason Playstation and N64 removed as much assembler code as
>possible - the RISC chips involved have funky rules for assembler.

There is nothing "funky" whatsoever about programming the R3300
(Playstation) in assembler. The only two things you have to keep
in mind are the one instruction load and branch delay slots; it
cannot get more trivial than that.

Compare this to programming, say, a Pentium in assembler, where
you have to know which instructions go in which pipe, and more.

Anyone saying that RISC chips are intrinsically harder to program
by hand obviously haven't tried programming RISC chips by hand.

[Klaus.S...@home.ivm.de]

>
> Re: Why isn't ASM the game language of choice?

In the case of my game it will be simple: If anyone isn't satisfied with the
mixture of Scheme libs and C modules that it comes with, he's free to rewrite
the whole stuff in the assembly of his own particular hardware platform .
Easy that is.

Klaus Schilling

[Carlos DaSilva]

Russ Williams wrote in message <6djlaa$hce$2...@usenet40.supernews.com>...

>Jason Shankel wrote in message <34FD04...@seesig.for.address>...

>[...]
>>But otherwise, your marketing department and your friendly
>>neighborhood VP of Production are not likely to give you an
>>extra six months on a project so you can get it 10% faster.
>

>With 6 extra months, I can think of better ways of getting at
>least a 10% speed-up. Moore's law, for one ;)
>
>(6 months would get an average 26% speedup, just by
>waiting).

Wow, Russ, I didn't know your computer magically upgrades itself without
intervention. Please share this technology with the rest of the world.

CJD

>---
>Russ

[Carlos DaSilva]

Sean Timarco Baggaley wrote in message <$NA9GjAY4X$0E...@dial.pipex.com>...

>In article <matthewpE...@netcom.com>, Matt Pritchard
><matt...@netcom.com> writes
>
>[...]
>
>>: 5. C code is more readable, less buggy on average
>>Disagree - depends on the programmer
>
>What? You seriously find x86 assembly easier to read than C? Give me
>Motorola 680x0 -- or even Zilog Z80 -- any day. At least they didn't go
>out of their way to make life harder for the programmer.
>
>C has the advantage of actually making sense when you read it. Even the

>semi-colon makes sense -- it is, after all, merely dividing the elements
>of a list.
>

>Where assembly excels is in speeding up critical code when no
>alternative exists: the central texture mapping loop of a software
>renderer for instance.
>
>But there comes a point when further optimisation is pointless: if your
>cut-scene FMV rendering code is already running at the maximum frame-
>rate of the animation, there's nothing to be gained in making the code
>any faster. If you can achieve that frame-rate in 100% C (and that has
>been done), there's simply no reason for using assembly aside from ego.

Duh, to make that same FMV rendering run at maximum frame-rate on SLOWER
computers. That's why you have to optimize. No wonder games today require
mega computers when programmers think like you (Oh, it runs acceptably on my
P333, ship it.)

CJD

>3D graphics engines are also approaching the point when assembly-coded
>optimisations are redundant: hardware acceleration is taking its place.
>(And with 1Ghz CPUs just around the corner you may yet see Quake clones
>being written in Visual BASIC...)
>
>

[Carlos DaSilva]

James David Chapman wrote in message <6di8t3$9l6$1...@heliodor.xara.net>...

> The results of my earlier trolling of various threads on this group

>were predictable, if a little sad. However, it was not my intent to
>aggravate for the sake of it. There is a very serious point here.

>
> A few people have compared early pac man with the modern games we
>see today, and laughed. Yet I have no doubt the original pac man
>*was* as complex as the game engines of today. Just think about it...
>Were the programmers of then less clever than us? Why didn't they
>come up with DOOM? The answer is of course simple, they were packing
>features into machines which were too small, and running amazing

>routines on processors which were too slow. They achieved the

>impossible and their code was like poetry, and like poetry, there had
>to be strict limits for it to work. But, how often do you find
>beautiful code like that today?

Exactly, although people like Russ and Mr. Shankel think of code complexity
in terms of "x" number of lines.

Programmers in the past didn't have the fancy compilers and debugger and
whatnot we have today. They also didn't have the copious amounts of disk
space, memory, processor speed, etc. But they made their games work (and
although Russ seems to think that those games, usually made in assembler or
machine code, were much simpler to write than today's "finer" games, he goes
on to say that coding in assembler leads to many stupid errors. Conflicting
logic there.)

> Well you don't come across it very often. Yet, hidden deep at the
>bottom of almost all the great games, you *will* find it... the
>reason? You just can't run massive numbers of instructions through
>the processor every 1/30th sec. You have to have a highly optimised
>machine language game engine. The engine must fit into the processors

>cache, it must be interleaved, it must be written again and again,
>until it is the most efficient it can possibly be.
>
>

> Now, I accept entirely that unoptimised ASM will produce code

>comparable with a C compiler, and that it can take longer to produce.

>However, at some stage, if you want to write a *game*, you are going
>to have to get your hands dirty. You are going to have to write

>machine level instructions. As I have said, inner game loops *must*
>be machine code of the highest quality. Support routines such as
>sound, video, timer etc. all require low level hardware coding.
>Machine coding. Any movement of pixel data must be done with
>assembly, since most of the time in a gameloop is still spent doing
>just that... and as for maths, clearly there is no alternative. Even
>efficient memory management must be done in assembly. So what else is
>there? The menus. Okay, you can do them in C if you want, but if

>you try to code everything in C, only dropping out occasionally to a
>bit of inline, then when are you ever going to learn the skills

>required to write those optimised game loops? I am unashamed to say

>that it took me 5 years to learn the m/c skills needed for a game

>engine, and now I find that these skills are dying out, due to what I

>see as the inappropriate, over usage of C.
>
>

> You can never complain about Microsoft churning out average software
>like a sausage factory, without accepting that C must take some of the

>blame. C *is* easier to write. Assembly *does* take more time to
>write, and *is* harder to read. This is not a bad thing, and far more

>crucially, it is not, as Jason suggested, an anti-commercial thing.

>We can argue about Microsoft and a whether quality is their Achilles

>heal another time, but you must agree that where games are concerned,
>people buy quality, and if games can be improved by machine code, then

>the industry had better wake up and start hiring, or it may find that
>a different section of the unwashed will be driving the Ferraris.
>
>

> I had not intended a 'my language is better than yours' debate, with

>all the tedious personal attacks and insinuations about programming
>style that USENET is famous for. I was simply reminding you that
>although C is dominant in the games market place today it need not

>always be that way. It seems people are confusing the work they do in

>their business programming with games design.
>
>

> I am interested in why *you*, the *games* programmers are
>programming in what I, and the programmers of yesteryear would
>consider a mid level language, the only true benefit of which is
>portability, which clearly *is* a benefit, but one which comes at a

>price. The price of making your code non-machine specific is speed.
>It will always be so. You cannot claim that C gives both, there must

>be a compromise somewhere.
>
>
> For me, the compromise it too great. For you it isn't. I am
>interested to understand why.
>
>

>James David Chapman.

Couldn't bear to snip it, makes good sense.

CJD

[Kevin Kwan]

Well, I agree with you totally. It is very easy for a programmer to be
veiled by the "relative ease" of programming in Common SDKs and Midlevel
languages to recognize the fact that, despite how large his ego is, the
code written by any compiler, no matter how good or how new it is,
frankly sucks when you compare it to hand optimized assembly code.
And in an industry in which game engine is fundemental, unlike any other
branch of the Information systems industry, where a reasonable solution
is good enough, the industry have been slamming users with not-so-good
code written in C++, C or Pascal that requires users to buy newer and
newer hardware just to stay alive. I mean, I don't mind buying a new
machine to run a new Operating System, a new 3D Rendering System, or a new
productivity package, but if I want to buy a new flight simulator (FS5 ->
FS6, FS6 -> FS7), I'll often have to get a new motherboard, a new 3D card,
more memory, and a CPU to stay alive, and the money I put in is often not
worth the results. It's not like my PC has been made
slow (My P166 still screams power in Windows 95, I can still multitask
Office 97 perfectly with Photoshop 4), but it's that programmers who would
not think twice about overkilling High Level Languages and have C and C++
compiled Assembly code waste CPU Cycles (You have NO idea how C++
compilers actually did a bad job in optimizing Pentium code, sometimes
causing Pipeline stalls for the sake of utilizing the V-Pipe in a couple
of MOV instructions...and in the Superscalar Pentium, that's a major
headache) in games that cause a game like iF-16 to choke on my computer,
while the graphically superior Novalogic F-22 Lightning can run better on
a computer that is 35% slower.
Of course, ultimately, many users will get so fed up with the lack of
feeling of responsiveness on a game even with its super-duper features
on the fastest possible machine that either they'll jump ship to console
games (The mass migration to the playstation, which have roughly the
firepower of a P90 with a Virge VX card and some zippy DSPs attached,
already made some PC games manufacturers uncomfortable), play older and
more proven games (Emulators, games from 1994-5) or are forced to buy
games with less features (or don't enable them) to play them on their PCs.

Anyway, what I'm saying is, despite the propaganda Intel continues to toss
around saying that you're less than human if you don't have a Pentium, and
then you're pond scum unless you have MMX, and you're a dung beetle if
your PC is not a P2, when you look at the way the PC is organized, the CPU
actually spend a lot of time waiting for other components to respond, and
the CPU still are not as powerful as some programmers would like, and in
certain critical routines, You'll still have to drop to NASM to do a
little creative Assembly to code certain routinesto make them play better.
Often, the newest features, the newest technology and the best graphics
does not automatically guarantee sales, It's gameplay and editability.
Who cares about the 16 bit bitmapping, the super-duper realtime campaign
engine, the superduper AI, or thousand polygon bitmapped meshes if it only
runs at 9 fps on an average Joe's PC, even if the features are turned off?
Then what do you get? No sales. And despite all the gaming magazine's
suggestions that everybody have a 3dfx and a P2, guess what, 65% of the
home computers today are still 486s and Vanilla Pentiums, and the number
is even higher in Asia and Europe.

Anyway, I totally agree that Assembly should be an option in the arsenal
of a game programmer, and as a disciple of Michael Abrash, I totally agree
with him on the fact that, as long as Compilers cannot reach the level of
sophisication as the compiler between your ears, Assembly will never be
obsolete.

:)kev

On Wed, 4 Mar 1998, James David Chapman wrote:

>
>
> The results of my earlier trolling of various threads on this group
> were predictable, if a little sad. However, it was not my intent to
> aggravate for the sake of it. There is a very serious point here.
>
>
> A few people have compared early pac man with the modern games we
> see today, and laughed. Yet I have no doubt the original pac man
> *was* as complex as the game engines of today. Just think about it...
> Were the programmers of then less clever than us? Why didn't they
> come up with DOOM? The answer is of course simple, they were packing
> features into machines which were too small, and running amazing
> routines on processors which were too slow. They achieved the
> impossible and their code was like poetry, and like poetry, there had
> to be strict limits for it to work. But, how often do you find
> beautiful code like that today?
>
>

[Carlos DaSilva]

Russ Williams wrote in message <6djla4$hce$1...@usenet40.supernews.com>...

>James David Chapman wrote in message <6dim1g$h6s$1...@heliodor.xara.net>...
>>Matt Craighead <crai...@citilink.com> wrote:
>[...]

>>>1. DirectX/OpenGL
>>
>> Is not really the issue here,
>

>Yes, it is.

>
>>it may be a big thing in the world of windows,
>

>You're an 3l337 DOS koder? Why am I not suprised?
>

>>but assembly programmers have had full video control
>>for years.
>

>Get a fucking clue. Mode 13h / Mode X is completely pathetic.
>Do you seriously think that asm offers any advantage for writing
>to video RAM?
>
>char *vga=(char *)0xa0000.
>
>Real difficult C, that.
>
>Try using asm to get 3d *acceleration* on, say, a Riva128.

Try to get Direct3D to do anything special on a Riva128. I can practically
feel the code going through layer after layer of Microsoft code before it
ever touches the hardware. Riva128 hardware test programs at NVidia probably
run 3-4 times faster than Direct3D's support of Riva128.

CJD

>---
>Russ
>
>
>
>

[Kevin Kwan]

> : Well you don't come across it very often. Yet, hidden deep at the

> : bottom of almost all the great games, you *will* find it... the
> : reason? You just can't run massive numbers of instructions through
> : the processor every 1/30th sec.
>

> Ten million's enough for me ...

Not as much as you think. Remember, even on fast Pentiums and P2s, some
instructions still takes 7 or 8 cycles to complete, and on Superscalar
CPUs, result dependent instructions will have to wait until the
calculations are complete or the data loaded into the register, and until
then, all the instructions will have to wait, often stalling the
instructions in the pipe up to 7 or more cycles. Not to mention the time
penalty in cache misses, memory wait states, and etc, the CPU is not as
well fed as you would think.

> You have to have a highly optimised
> : machine language game engine. The engine must fit into the processors
> : cache, it must be interleaved, it must be written again and again,
> : until it is the most efficient it can possibly be.
>

> Nope; on current hardware, the game engine can consist of a series of
> calls to DrawPrimitive at the bottom of a loop written in interpreted
> BASIC, and will still run faster than Michael Abrash could possibly
> imagine. HARDWARE ACCELERATION WINS.

Yes, But the argument is, Are you going to make your target audience buy a
new hardware in order to run it at any reasonable speed? For the price of
a 3dfx Voodoo Video Card and a 3dfx comptible game (which require a 2D
card), you can get a Sony Playstation, a couple of games and the
Playstation would possibly deliever its best everytime, unlike the
numerous bugs and errors Windows 95 and DirectX can still create.
Remember, Everytime you load a new device driver into Win95, it's an
opportunity for bugs. The truth is, over-reliance on hardware that is not
standard all across the board is disaster for sales. And the sad truth is
that the most popular 3D card in terms of numbers installed in the PC is
the S3 Virge, which is not nearly fast for anything, and 3dfx is still a
minority (A growing minority, but a minority)
Well, Until the i740 Auburn or 3dfx Voodoo/V2 becomes a PC Standard like
the Soundblaster, I'll still stick to assembly optimized code and go for
the larger audience.

:)kev

[Louis Tremblay]

You got 2 months... :)

bye,

[Drake Christensen]

I've only read about half of this religous war thread. I do have two
cents to toss in.

As Brandon pointed out, the differences between ASM and C are
relative. In some cases one is "better" and in other cases the other
is. That ignores whether the "worse" one was good enough. As Jerry
Pournelle often piths, "Better is the enemy of Good Enough."

For my contribution, I suggest looking at ALL of the tradeoffs.
Here's an admittedly incomplete list:

- Code speed
- Code size
- Pool of available programmers
- Cost of said programmers
- Time need by the team to implement the game (ie, release date)
- Target performance for each piece of the game and the game as a
whole
- Time/cost to address make or break performance concerns late in the

project (ie, exploring new algorithms)
- Time/cost to take advantage of changes in the installed base (ex.
3D cards, and a few years ago modem->LAN and LAN->Internet)
- Time/cost to take advantage of entirely new markets (consoles)

From what I've seen in this thread, you're looking at the first two
and discounting all of the others almost completely. To me, probably
the most important is the performance targets.

Not all games need ASM. For example, one can write a fine card game
or puzzle game in VB. VB might also work for most Myst-like adventure
games. A 3rd-person Sierra-type game would probably be better served
by C/C++, and would likely get by without any ASM. A Quake or a Sonic
the Hedgehog is probably going to have a few tight loops where every
cycle counts.

My favorite example in the ASM vs C/C++ war is Doom. It was written
in 99+% cross-platform C with exactly two routines written in ASM.
As-is, Doom was a huge success. Could it have been better? That
depends on what you mean by better. Most suggestions on improvement
concentrate on gameplay issues. Would more ASM have helped address
those gameplay issues? Maybe. Again, it depends. For example, you
wouldn't need to resort to ASM to change how a level was laid out, or
to add a jump command.

Doom was good enough for most of its customers. And Quake has become
a phenomenon. I contend that those two programs demonstrate that the
*thoughtful application* of ASM is what one should be aiming for. The
sweeping generalizations "ASM is better" or "ASM is dangerous" are
basically nonsense phrases. There are too many variables for anyone
to be that dogmatic.

[Kevin Kwan]

> >>With the release of the IA-64 chipset, the complexity of
> >>writing ASM code will be so high that a C compiler will
> >>produce faster code than probably every assembler
> >>programmer for large programs.
> >
> > I don't think games are large programs.

Yes, But their data structures are huge...Ever think about that? A game
engine can be only 256k to run a VESA 800X600 256 color game that can
pound 2000 polygons at 25-30fps, but the amount of data they need to
swallow from the slow systems memory to run them also mean that
intrisiticly, games with features overkill will run slower if the
information they need is not on the system cache.

> Then you must be completely bereft of clues.
>
> >There is simply no time to pass huge volumes of instructions
> >through the processor in a game engine,
>
> Wow, such naivete. That must be why modern games only have
> 16k of code, then...
>

Code and data are two different things.

> >the system memory is too slow.
>
> Yup. There's only about 100megs/s of usable bandwidth...

Yeah, But have fun waiting for the memory to respond. Even with a
486DX2-50, one cycle is 20ns, and since read/write times slices that in
half, that means that in order for the CPU to synchrinize with ther
memory, the memory must have a wait state of only 10ns...And on a typical
486, the wait time is ~70ns. So guess what, no matter how much bandwidth
there is, you'll still have to wait for the data to pour out. Even though
the System Cache can help, if you run into a cache miss, you'll still
have to wait for the memory to rev up and deliver.

>
> >>And it seems this trend will continue, since many other
> >>hardware manufacturers are looking at removing
> >>complexity out of the chip and into the compiler.
> >

> > I chose to program the x86 partly for commercial reasons it
> >has to be said. However, this was underpinned by a love of
> >the richness of its instruction set. When the chip is totally
> >RISCified, I will have to consider moving on.

Well, That makes x86 such a challenging and fun CPU to work with.

> What about the commercial reasons? Intel isn't going to let
> go of the PC market, so 90+% of computers will still be
> running Windows on Intel CPUs.
>
> >From intel's point of view I kinda understand, there is very
> >little they can do to make the chip as a whole go any faster,
> >it is already pushed to breaking. It is a shame though, since
> >the instruction set is the only thing which differentiates the chip
> >from the competition, and of course, they are only passing the
> >bottleneck on to the poor memory developers, who will have
> >to cope with vast amounts of compiler code to shift about.
>
> Compiler code is bigger than asm? Since when? The
> differences are minimal, and only fuckwits like you insist
> otherwise. A modern compiler does at least as well as a
> competent asm coder. Like chess, optimisation is a small
> set of simple rules that a computer can execute well, without
> getting tired or bored or making mistakes (so long as the
> rules are correct). A talented human can win by seeing 'the
> big picture', but for simple by-the-book optimisation (squash
> AGIs, pair instructions,...), the compiler will be just as good
> in most cases.

Oh really? Even by coding a control structure just a bit differently in C
will cause code bloat! Have you read Microsoft Press's "Writing bug Free
programs?", even though the book is a bit old, many of the rules still
apply!
Besides, careful programming in ASM will always deliever faster and
smaller code, and not every compiler can see beyond the big picture to NOT
pair instructions several cycles afterwards that can cause AGIs.

> >> Good hand assembly will become almost impossible.

> > No-one ever said programming in assembly was easy. :D
>
> It's not exactly difficult. More time consuming than anything
> else. Optimising a few small routines can even be fun (like
> logic puzzles or crosswords).

Well Yes, I'm not exactly saying that you should do everything in ASM and
screw C or C++, but sometimes, several interwined routines run better if
they are all ASM, not just the "time critical" areas. And besides, with
ASM, If you did it right the first time, everything will go smoothly. Not
so C or C++. You change a bit of code, and you might end up re-writing
half of an important function.

:)kev

[Rick Genter]

James David Chapman wrote in message <6djk4e$4rl$1...@heliodor.xara.net>...
>>Code reuse
>
> I have *never* had *any* problem with code reuse in asm. Both
>languages can be written out well for other people to read, both can

>be written out terribly badly. People are put off learning Asm
>because assemblers don't come with a huge library of routines, you
>have to write them yourself, but once you have them, asm and c look
>very similar to program, and one *is* faster.

Really. Your PC assembly language code just runs on the Playstation with
only a recompile? I'm impressed.

> I
>believe that a company which shoulders some of the cost of code
>optimisation, will be rewarded by the consumer.

You're naive.

--
Rick Genter
VP, R&D
5D Games, Inc.
<mailto:rge...@5dgames.com>
<http://www.5dgames.com>
ICQ UIN# 8291497

[Rick Genter]

Sean Timarco Baggaley wrote in message ...

>If I'm faced with a choice between spending a month optimising for a
><10% increase or spending that same month getting the *gameplay* right,
>I'd choose the latter every time.

Bravo!

[Kevin Kwan]

> Far from being sad, I think it's a great development. Instead of
> writing code so that process X meshes exactly with the screen
> resync, or so that hardware input Y is read at exactly the right
> time, we now have to worry about actual gameplay.

Which modern games lack immensely. Having good graphics and good sound
simply doesn't mean that a game is good. It's the game reaction time, the
feeling of control, the illusion of speed and the immersiveness that
counts.

> Of course, the weenies in this group will still go on about the
> need to write in asm, or which compiler to use, or which OS
> is best, and so forth. But, fortunately, the days of these
> people are numbered. Two years ago in this group, the same
> weenies were claiming that DOS will never die and that there's
> no way in hell they'd be writing games for that Windows rubbish.
> Once we get these people to understand that writing games isn't
> just about writing a DOS/Win32 application, perhaps we'll actually
> be able to have discussions in this group about *game* development.

Yeah, The same weenie tots also relized that Win95 code is bloated, slow,
are subject to more device driver bugs, and does not offer the same type
of gameplay that its predecessors do for the sacrifices it made.
Just take a look at the difference between Simcity 2000 DOS and SC2000
Windows 95. Identical, but one requires a higher class of CPUs, have
problems with Video drivers in Windows 95, reacts slower in panning
functions, and is generally not as good. If it is me, I'll rather run
SC2000 DOS under a DOS Box in Windows 95 than to play the Win95 native
version. And remember, the same weenie tots did not choose Windows as a
programming platform. It's the lack of viable alternatives that piss them
off. And trust me, many still use Allegro for DJGPP for serious game
programming, sprinkled with ASMs now and then. And once again, discussing
which platforms to develop to is still a major part of game development,
and this newsgroup does not always seriously deal with issues in game
development.
It is often used as a place to flame newbies or curse people with ideas
that are different than yours. Whatever happened to tact and etiqette?

:)kev

[Kalrithian]

Thomas Womack wrote in message <6djvgi$kie$9...@news.ox.ac.uk>...
:Kalrithian <eem...@txdirect.net> wrote:
:
:: This is an interesting phenomenon. As memory and disk space become

cheaper,
:: there is less and less push to squeeze stuff into them. Take Windows 95,
for
:: example. I think that most of those features could have been implemented
in
:: much less memory and disk space. Case in point: the startup and shutdown
:: splash screens are stored on disk as uncompressed BMP files.
:

:Take Quake ... sets of textures stored in each .BSP file. Take Quake

:][ - everything done in uncompressed .PCX or .TGA files. Note that a
:large number of BBC Micro games were not much reduced in size by
:something like PKZIP, due to habits like storing a map with 32 sorts
:of tile in 5 bits per tile and decompressing at runtime.

:

Reading uncompressed data also tends to be faster than compressed data,
especially if the OS is doing disk caching.

Kalrithian

[Kevin Kwan]

> Kevin Kwan wrote in message ...
> [...]

> >(You have NO idea how C++ compilers actually did a bad job in
> >optimizing Pentium code, sometimes causing Pipeline stalls for
> >the sake of utilizing the V-Pipe in a couple of MOV instructions...
> >and in the Superscalar Pentium, that's a major headache)

> [...]

> >the CPU actually spend a lot of time waiting for other components
> >to respond,

> [...]

> >You'll still have to drop to NASM to do a little creative Assembly to
> >code certain routines to make them play better.
>

> OK, feel free to correct me if I'm wrong, but from these 3 comments,
> I'd guess you're writing DOS code in DJGPP/NASM. I'll assume that
> is the case.
> i) DJGPP *doesn't* *do* Pentium code (it thinks a 486 is
> state-of-the-art), so your first point is wrong. The way most of us
> know Watcom or MSVC optimise well is from looking at the
> disassembly of our code.
> ii) Under Windows, most things are done on callbacks and polling
> is heavily deprecated.

Actually, I do development on DJGPP with Allegro (And yes, DJGPP does have
Pentium Support, but you'll need to find the right patch for it)
and I aso use Metrowerks Codewarrior Release 1 to do alot of
cross-platform programming and Watcom 11 to do most of my Hybrid compiling
if I'm forced to use DirectX in a game.

> >Then what do you get? No sales. And despite all the gaming
> >magazine's suggestions that everybody have a 3dfx and a P2,
> >guess what, 65% of the home computers today are still 486s
> >and Vanilla Pentiums, and the number is even higher in Asia
> >and Europe.
>

> So, you'd advise us to spend months making our code work on
> 486s, in the hopes that someone with no money to upgrade will
> suddenly go out and spend $50 on a game? Not going to happen.
> 486 owners tend to either not buy software, or buy $10 budget
> games. It's very simple: The people with money for games have
> money for hardware.

That is also another very naive comment. The folks in 486s don't buy
expensive software becuase their PC can't handle it. However, they do
tend to buy software that works well for them...Target audiences.
And since if your game have a are installed player base, you are
guaranteed a more steady customer base instead of the initial rise and
then rapid fall. Take Doom, For example. If the folks at id did not make
it possible for lower end 386s to play with the 486 big boys, you think
they'll actually still have customer today? Same with Spectrum Holobyte's
Falcon 3. Since it supports 3 CPUs and have a very lenient features base,
not only the 486 crowds snapped it up. The 386 and the 286 also.
Perhaps Civilization. Its ability to run from an 8086 to a Pentium 200 MMX
guarantees immortality. I mean, if you think about it, more people are
inclined to buy FS5 than FS7, because they don't own P2-233s, they can't
see the really large differences between the 2, and frankly, FS98s
requires something that not alot of people can afford until it is older.

> >Anyway, I totally agree that Assembly should be an option in the
> >arsenal of a game programmer, and as a disciple of Michael
> >Abrash, I totally agree with him on the fact that, as long as
> >Compilers cannot reach the level of sophisication as the
> >compiler between your ears, Assembly will never be obsolete.
>

> Here's a quote from Abrash's "Graphics Programming Black
> Book Special Edition" (p1112, referring to in-order tree walking
> code, 32-bit VC1.1 under NT)
> "Things change when maximum optimization is selected, however:
> The performance of the two implementations becomes virtually
> identical! How can this be? Part of the answer is that the compiler
> does an amazingly good job with Listing 59.2. Most impressively,
> when compiling Listing 59.2, the compiler actually converts all
> right-subtree descents from code recursion to data recursion,[...]"
>
So? It has also been proven that certain coding styles in C and C++ will
generate fatter code. Perhaps the author understand what certain coding
styles will do when a compiler interprets them will do, and avoids C code
that promotes code growth. Once again, if you have no knowledge of
Assembly and understand what some compilers will do to your code, you'll
miss out.

> Compilers have come quite a way since then (the main difference
> between VC4 and VC5, for example, is a complete overhaul of the
> compiler).
>
> The view that humans will always be able to out-optimise compilers
> is very naive[1]. A lot of optimisation is simple rule-following (for
> pairing instructions, register usage, avoiding stalls, etc.), much like
> chess. Sure, Kasparov can beat most computers, but almost
> everyone else on the planet can be soundly beaten by a home PC
> and a chess engine cranked up to max difficulty...
>
Guess what, set rules and an imaginative humnan mind are never
evenly matched. You can never perdict whether Gerry Kasparov will
challenge Deep Blue again to win. And guess what, Compiler technology are
not exactly up to the point of Deep Blue's expertise in chess, and on a
home PC, while waiting minutes for the computer to run through its AI to
choose a correct move is acceptable, having the compiler spend hours on a
program to generate code that can beat hand-optimized assembly is just
wrong. (and trust me, that can't be done on a Pentium...In order for a
compiler to make code this clean, it'll take days)
A Human mind still cannot be beaten when it compares itself to a
pegboard of set rules. Maybe the compiler can step through and
revise routines faster than a human can, but the human, with innovation,
experience and a bit of time, will always ended up with cleaner code.
>
> [1] - Of course, this is always going to be true - we can always just
> use the compiler to generate the asm for a draw, but it's a matter
> of whether it's possible to do that without 'cheating'. I'd bet that
> VC5 will already beat most programmers at x86 assembly.

Yeah, but VC5 probarbly also offer many features that'll drag the benefit
of an efficent compiler to a moot point.

:)kev

[Kevin Kwan]

> Optimising takes time, which costs money. Making a game run on
> machines less than your target platform costs more money and
> there's no way to make it back. Publishers aren't too happy about
> developers 'wasting time' like that. After all, they're paying for it.

What? And spent months patching a game that runs too slow after its
initial release, thereby pissing off half the buyers?? Or would you like
to offer an SE version with the optimized patches and charge John Q Player
as much money to buy a version with features that should've been there ion
the first place, causing negative publicity? What causes more money?
Pissed off customers who wouldn't buy your software, or developers who
make sure that their software rings a bell with the customer base for
their performance?

> Just like a Linux port - nice, but it's going to lose money.

Yes. But then with a Linux port, you're guaranateed to corner the entire
market. Check out Quake...Who on Linux hasn't at least a copy of it?
At least id is smart enough to reach out to the 8% of the PC owning
population and show that they care, not to mention it makes for a huge
boost in customer loyalty and namebrand recognition? id has Q and Q2 on
the charts for almost 3 years, and Quake still have tons of fans who'll
buy any followups and sequels.

:)kev

[Chris Lomont]

Gerry Quinn wrote in message <6djq6f$3l$1...@news.indigo.ie>...
>In article <6dir7a$l...@mozo.cc.purdue.edu>, "Chris Lomont"

<clo...@omni.cc.purdue.edu> wrote:
>
>>And it seems this trend will continue, since many other hardware
>>manufacturers are looking at removing complexity out of the chip and

>>into the compiler. Good hand assembly will become almost impossible.
>>
>
>Don't underestimate human ingenuity. Or overestimate compiler
>quality.
>

Or vice versa!

Chris Lomont

[Kevin Kwan]

> >>Code reuse
> >
> > I have *never* had *any* problem with code reuse in asm. Both
> >languages can be written out well for other people to read, both can
> >be written out terribly badly. People are put off learning Asm
> >because assemblers don't come with a huge library of routines, you
> >have to write them yourself, but once you have them, asm and c look
> >very similar to program, and one *is* faster.
>
>
> Really. Your PC assembly language code just runs on the Playstation with
> only a recompile? I'm impressed.

But then, Since when did you ever simply recompile a program for a
different target platform and then everything will be hunky-dory?
Also, show me one company that at least didn't use some assembly in their
code that you'll have to rewrite?
Now Who's being naive?

> > I
> >believe that a company which shoulders some of the cost of code
> >optimisation, will be rewarded by the consumer.

I totally agree. The company that offers the most features for the least
amount of hardware (read: Assembly optimized) will usually be rewarded
than the company who pounded out code the quickest and runs the lousiest.
>
> You're naive.

Now Who's being naive?!

:)Kev

[John Poole]

James David Chapman wrote in message <6djk4e$4rl$1...@heliodor.xara.net>...

>Jason Shankel <JasonS...@seesig.for.address> wrote:

>>> >1. DirectX/OpenGL

>>
>>You cannot get such access to 3d hardware in any other way. You simply
>>do not have the option of register programming these cards, you must use
>>an API.
>
> Hardware manufacturers will soon learn not to keep their internal
>specs to themselves.

Ummm, why is using a general API like OpenGL a Bad Thing? You write one bit
of code that runs on *all* the 3D cards out there that support OpenGL. The
alternative is to either write one set of code that utilizes the hardware
API of a certain card (thus excluding all the users out there who don't have
that card), or writing multiple sets of code for each hardware API out there
(thus not taking advantage of cards that come out after the release of your
game). Plus, writing more sets of code creates a larger code base *and* has
the potential for introducing more bugs.

What was the compelling reason for programming directly to the hardware API?

--
jfpoole - {}
http://www.undergrad.math.uwaterloo.ca/~jfpoole/

[Chris Lomont]

James David Chapman wrote in message

<6dl0b4$f8t$1...@heliodor.xara.net>...
>
> Hmm, the thread title is "why isn't asm the game language of
>choice" I now understand fully that, "time and money" are reasons
for
>some people, however, I note that given all the time in the world
many
>would still choose C, which is, in my opinion, [still!] wrong.

Since you are free to toss time and money, what if I choose to use
another hypothetical device - the perfect optimizing C compiler. Now
which is the better language?

Since time and money are not likely to go away, but compilers are
steadily increasing on the pure asm programmer's optimization tricks,
and gives a lot better portability, which is better?

> Yes I am sorry, I have completely assumed demanding graphical games
>and totally forgot the other types of game for the purposes of this
>discussion.

Even these games need very little asm. Descent and Doom code are out
to look at. Take a peek.

>>My favorite example in the ASM vs C/C++ war is Doom. It was written
>>in 99+% cross-platform C with exactly two routines written in ASM.
>>As-is, Doom was a huge success. Could it have been better?
>

> If at the time of release, someone had come up with a version of
the
>game in asm, they could have had more monsters with the space they
>saved for a start.

And shipped two years later, and not been able to port to all the
platforms they did in so short a time, etc, etc, etc.....

>>The sweeping generalizations "ASM is better" or "ASM is dangerous"
are
>>basically nonsense phrases. There are too many variables for anyone
>>to be that dogmatic.
>

> Mmm, the generalisation to which you refer was a little more
>specific than that, I contended that: asm is the better.. ..choice
for
>games programming.

Based solely on final exe speed? This outweighs development time/cost
and portability to other platforms (Win95, N64, and Playstation)? I
know for a fact that a recent game I did contract work for was cross
developed for Win95 and Playstation, and the N64 port is underway. If
the original PC version was x86, lotsa lost revenues and higher costs.
These are what make a better choice for game programming. Unless in
the fantasy world one has the same assembler instructions on all
platforms, then perhaps this arguments weakens.

> This contention certainly *used* to be true. No-one can seriously
>disagree with that. I started this thread because I see all this C
>code knocking about and wonder whether it is *still* true, and the
>games industry is wide of the mark.

It used to be true all programming had to be done at the binary level.
As the complexity of code increases, so does the need for better ways
to abstract all the 0's and 1's to managable complexity levels.

For games, the bottom line seems to be it is faster to develop in C
and the added portability for many routines like AI, collision, etc,
make it financially sound to develop in C, and if no asm is needed for
the final product, so be it.

Chris Lomont
(who once coded a Sega game in 68000 assembler - The Mask, sadly never
released but all the screen shots still exist in mags! - and some
sound routines for said game in Z80, an animation editor for his
Color Computer in 6809 as a kid, and tons of x86 stuff. I prefer C++
nowadays)

[David Wareing]

In article <6dk6ms$2vn$1...@kodak.rdcs.Kodak.COM>, "Mirkurius"
<mirkuriu...@hotmail.com> wrote:

> >Yes. That's because it takes talented programmers to make
> >a great game - and they tend to write very elegant code.
>
> Actually, a lot of modern code is very ugly.

Indeed. I've seen professional game code that wouldn't pass
muster at the Annual Ugly Code Awards.

> Take a look at the Descent
> source code that was recently released, and thats considered an excellent
> modern game that broke new ground. The shear amount of algorithmic logic
> needed to code most games today combined iwht the whips wielded by
> publishers and venture capitalists leaves little time for making the code
> pretty.

^^^^^^

You misspelt 'useful, adaptable and readable'. ;) Prettiness isn't
the least important factor in programming (how you order your
workshop dictates in part how well you'll produce your work) but
elegant code is not code which is merely pretty. Elegant code
is useful, well designed code that can be adapted when required.

IMO, 'Descent' is a fine piece of technology (it's not my type
of game), but the source code shows that it's been more cobbled
together than designed. It's obvious at a glance that much
revision is needed to the code in order to produce variations
or sequels, or entirely new games from the existing code base.
As it is, the code doesn't allow itself to be modified easily.

> Obviously, though, it is the mark of a good programmer to write as
> elegently as possible.
> Also, if you look at the code for very early games, especially consoles like
> the Atari 2600, it is very amazing what they managed to do in such little
> space. VERY elegant. coders dont write like that any more because they don't
> have to. That was mostly a memory issue, which is becoming less and less
> important. Its kinda sad, but so is the decline of the horse and buggy....

Far from being sad, I think it's a great development. Instead of

writing code so that process X meshes exactly with the screen
resync, or so that hardware input Y is read at exactly the right
time, we now have to worry about actual gameplay.

Of course, the weenies in this group will still go on about the

need to write in asm, or which compiler to use, or which OS
is best, and so forth. But, fortunately, the days of these
people are numbered. Two years ago in this group, the same
weenies were claiming that DOS will never die and that there's
no way in hell they'd be writing games for that Windows rubbish.
Once we get these people to understand that writing games isn't
just about writing a DOS/Win32 application, perhaps we'll actually
be able to have discussions in this group about *game* development.

--
David Wareing dwar...@adelaide.on.net
Macintosh Game Development <www.ambrosiasw.com/~dwareing>
Get Mars Rising: <www.marsrising.com>

[Russ Williams]

Kevin Kwan wrote in message ...
[...]

>(You have NO idea how C++ compilers actually did a bad job in
>optimizing Pentium code, sometimes causing Pipeline stalls for
>the sake of utilizing the V-Pipe in a couple of MOV instructions...
>and in the Superscalar Pentium, that's a major headache)

[...]

>the CPU actually spend a lot of time waiting for other components
>to respond,

[...]

>You'll still have to drop to NASM to do a little creative Assembly to

>code certain routines to make them play better.

OK, feel free to correct me if I'm wrong, but from these 3 comments,
I'd guess you're writing DOS code in DJGPP/NASM. I'll assume that
is the case.
i) DJGPP *doesn't* *do* Pentium code (it thinks a 486 is
state-of-the-art), so your first point is wrong. The way most of us
know Watcom or MSVC optimise well is from looking at the
disassembly of our code.
ii) Under Windows, most things are done on callbacks and polling
is heavily deprecated.

[...]

>Then what do you get? No sales. And despite all the gaming
>magazine's suggestions that everybody have a 3dfx and a P2,
>guess what, 65% of the home computers today are still 486s
>and Vanilla Pentiums, and the number is even higher in Asia
>and Europe.

So, you'd advise us to spend months making our code work on

486s, in the hopes that someone with no money to upgrade will
suddenly go out and spend $50 on a game? Not going to happen.
486 owners tend to either not buy software, or buy $10 budget
games. It's very simple: The people with money for games have
money for hardware.

>Anyway, I totally agree that Assembly should be an option in the

>arsenal of a game programmer, and as a disciple of Michael
>Abrash, I totally agree with him on the fact that, as long as
>Compilers cannot reach the level of sophisication as the
>compiler between your ears, Assembly will never be obsolete.

Here's a quote from Abrash's "Graphics Programming Black

Book Special Edition" (p1112, referring to in-order tree walking
code, 32-bit VC1.1 under NT)
"Things change when maximum optimization is selected, however:
The performance of the two implementations becomes virtually
identical! How can this be? Part of the answer is that the compiler
does an amazingly good job with Listing 59.2. Most impressively,
when compiling Listing 59.2, the compiler actually converts all
right-subtree descents from code recursion to data recursion,[...]"

Compilers have come quite a way since then (the main difference

between VC4 and VC5, for example, is a complete overhaul of the
compiler).

The view that humans will always be able to out-optimise compilers
is very naive[1]. A lot of optimisation is simple rule-following (for
pairing instructions, register usage, avoiding stalls, etc.), much like
chess. Sure, Kasparov can beat most computers, but almost
everyone else on the planet can be soundly beaten by a home PC
and a chess engine cranked up to max difficulty...

---
Russ

[Russ Williams]

Carlos DaSilva wrote in message <6dkhoi$4...@bolivia.earthlink.net>...
[...]

>>>but assembly programmers have had full video control
>>>for years.

[...]

>>Try using asm to get 3d *acceleration* on, say, a Riva128.
>
>Try to get Direct3D to do anything special on a Riva128. I can
>practically feel the code going through layer after layer of

>Microsoft code before it ever touches the hardware. Riva128

>hardware test programs at NVidia probably run 3-4 times faster
>than Direct3D's support of Riva128.

Just like DOS apps run 50-80% slower in Windows? Even if the
Riva128 is 3-4x slower than it could be, that makes it *scalable*
(upgrade to a P2-450 and it just gets faster...). It's still one of the
fastest consumer 3d cards available. (Anyone know if the
Voodoo 2 is faster?)

Besides, none of this has the slightest bearing on my point - you
can't get it to do *anything* accelerated under DOS. nVidia can,
but that's not much use to the rest of the world...

---
Russ

[Russ Williams]

Carlos DaSilva wrote in message <6dkhf1$4...@bolivia.earthlink.net>...
>Sean Timarco Baggaley wrote in message <$NA9GjAY4X$0E...@dial.pipex.com>...
[...]

>>But there comes a point when further optimisation is pointless:
>>if your cut-scene FMV rendering code is already running at the

>>maximum frame-rate of the animation, there's nothing to be

>>gained in making the code any faster. If you can achieve that
>>frame-rate in 100% C (and that has been done), there's simply
>>no reason for using assembly aside from ego.
>
>Duh, to make that same FMV rendering run at maximum frame-rate
>on SLOWER computers.

Why? 486s don't pay the wages.

>That's why you have to optimize.

Optimising takes time, which costs money. Making a game run on

machines less than your target platform costs more money and
there's no way to make it back. Publishers aren't too happy about
developers 'wasting time' like that. After all, they're paying for it.

Just like a Linux port - nice, but it's going to lose money.

---
Russ

[Russ Williams]

Carlos DaSilva wrote in message <6dkhf3$4...@bolivia.earthlink.net>...

My target market upgrades their hardware often. Merely waiting
until they do will get a bigger speed-up than asm can offer...

---
Russ

[Thomas Womack]

Kevin Kwan <kk...@acsu.buffalo.edu> wrote:

: Yeah, The same weenie tots also relized that Win95 code is bloated, slow,

: are subject to more device driver bugs, and does not offer the same type

: of gameplay that its predecessors do for the sacrifices it made.

Bloated? My .exe for number-crunching routines are about 3k long.

Slow? Less than the difference between a P2/300 and a P2/266.

And having device driver bugs is an unfortunate consequence of having
device drivers ... which DOS entirely lacks. I don't see the
sacrifices you're talking about: hardware accelerated graphics rather
than having to write to a block of memory, playing sound with
PlaySound() or DirectSound calls rather than working round the
intricacies of a dozen incompatible pieces of hardware, input with
DirectInput rather than polling a joystick manually don't look like
sacrifices to me.

: Just take a look at the difference between Simcity 2000 DOS and SC2000

: Windows 95. Identical, but one requires a higher class of CPUs, have
: problems with Video drivers in Windows 95, reacts slower in panning
: functions, and is generally not as good.

Um, I see the problem - but the one which requires faster CPUs, pans slower,
and interacts nastily with Win95 video drivers is the *DOS* version!

: It's the lack of viable alternatives that piss them off.

I've used Linux for a few months. I've used NT for a few months. I'm
still using NT, and where my Linux partition was is now an NTFS drive
containing a mirror of the Project Gutenberg archive.

The code for drawing a texture-mapped cube is about the same length
under DOS as under DirectX, counting initialisation routines. The code
for drawing a texture-mapped cube with hardware acceleration on any
card produced after mid-1997 is *the same length* under DirectX, and
*cannot be written* under DOS because people don't reveal
register-level designs for their hardware.

The hardware is now utterly irrelevant. And this is a Really Good
Thing.

Tom

[James David Chapman]

Thomas Womack <mert...@sable.ox.ac.uk> wrote:

>But CDs are cheap, and the cost of hard disc space is between three
>and five pence a megabyte. Quake ][ is still really big, though; I
>can't quite understand why the textures couldn't be stored on disc in
>.GIF format.

I agree, much of what I see in this whole thread, is justification
for lazy coding.

People have remarked on the size of disks and memory going up, and
used it as justification for the "why bother?" style of coding. Well
I'll tell you.... Unless you guys have the internet piped to your
house via telepathy, you are going to have to have all that
unoptimised data sent to you in 1k chucks.

A 5 hour download is a a major turn off to customers, and is just
*another* way they end up paying for your programming practices.

James David Chapman.

[Russ Williams]

Carlos DaSilva wrote in message <6dkh5g$4...@bolivia.earthlink.net>...
>James David Chapman wrote in message <6di8t3$9l6$1...@heliodor.xara.net>...
[...]

>>They achieved the impossible and their code was like poetry,
>>and like poetry, there had to be strict limits for it to work. But,
>>how often do you find beautiful code like that today?
>

>Exactly, although people like Russ and Mr. Shankel think of code
>complexity in terms of "x" number of lines.

As opposed to the number of brightly coloured machine tools in
a bathtub?

Complexity is due to a variety of factors, but the biggest is code
size. Finding bugs in a 5 line "Hello World" program is a damn
sight easier than debugging a single 1000 line module.

>Programmers in the past didn't have the fancy compilers and
>debugger and whatnot we have today. They also didn't have the
>copious amounts of disk space, memory, processor speed, etc.
>But they made their games work (and although Russ seems to
>think that those games, usually made in assembler or machine
>code, were much simpler to write than today's "finer" games,
>he goes on to say that coding in assembler leads to many
>stupid errors. Conflicting logic there.)

Why conflicting logic? Writing a game that fits in 32k of RAM is
one thing, writing a game with over 250klocs of asm is very
different. It's possible for an experienced coder to hold the
former in his head. The latter would require several people
working on it, and would be unlikely to be fully understood by
anyone on then project. Not grokking someone else's code is
probably *the* biggest source of errors in existance.

---
Russ

[James David Chapman]

Sean Timarco Baggaley <stbag...@hotmail.com> wrote:

>Pro-technology people are forever whining about how 100% pure ASM
>(orwhatever) is so bloody important, but it's bullshit. It's the
>*GAME *that's important. Code quality is secondary, since without a good game
>for the coders to actually work on, all that effort it pointless.

You can imagine any game you like, with all sorts of neat features,
and gameplay, but without an engine, designed to run on a particular
machine, you are just daydreaming.

Doom didn't come about by people sitting around thinking about how
neat it would be to frag people, it came about because someone worked
out how to code the 'bloody' thing.

>If I'm faced with a choice between spending a month optimising for a
><10% increase or spending that same month getting the *gameplay* right,
>I'd choose the latter every time.

Phew. Every 10% increase in optimisation allows you to add more
features to a game, thus improving the gameplay and commercial value.

>It's a 'mark-up language' -- that's what the 'M' and 'L' in 'HTML' stand
>for. Just because it ain't used for programming doesn't make it any less
>a language.

[So morse code with a bit of formatting is a language too?].

James David Chapman.

[James David Chapman]

"Carlos DaSilva" <cdas...@earthlink.net> wrote:

>Exactly, although people like Russ and Mr. Shankel think of code complexity
>in terms of "x" number of lines.

I had a noticed the same thing. You can guarantee that any 3Mb exe
file will have the complexity level of a blancmange. Most serious
coders have conceded that at the very least the inner game loops must
be tiny asm, so what is in the rest of the code? It can't all be
init routines and menus.

James David Chapman.

[Russ Williams]

James David Chapman wrote in message <6dku57$dpj$1...@heliodor.xara.net>...

>Sean Timarco Baggaley <stbag...@hotmail.com> wrote:
>
>>Pro-technology people are forever whining about how 100%
>>pure ASM (orwhatever) is so bloody important, but it's bullshit.
>>It's the *GAME *that's important. Code quality is secondary,
>>since without a good game for the coders to actually work on,
>>all that effort it pointless.
>
> You can imagine any game you like, with all sorts of neat features,
>and gameplay, but without an engine, designed to run on a particular
>machine, you are just daydreaming.

I think you've got the logic screwed up there. First of all, the onus is
on *you* to prove your assertion that "We're all doing it wrong".
Secondly, the *game* can exist on paper as design docs - that
requires approximately *zero* code (and even less asm...).

> Doom didn't come about by people sitting around thinking
>about how neat it would be to frag people, it came about because
>someone worked out how to code the 'bloody' thing.

id do things a little different to the rest of us. They keep doing the
same game with just new technology (even Carmack admits this).
Therefore, Doom probably did start with an engine. An engine
which is about 5% asm, BTW...

>>If I'm faced with a choice between spending a month optimising
>>for a <10% increase or spending that same month getting the
>>*gameplay* right, I'd choose the latter every time.
>
> Phew. Every 10% increase in optimisation allows you to add
>more features to a game, thus improving the gameplay and
>commercial value.

The only thing adding features improves is creeping featuritis...

The point you seem to be missing is that in order to be able to hone
gameplay, you can't spend the time fucking about optimising
every line of code. Not if you want to ship this side of the heat-death
of the universe.

Your attitudes seem symptomatic of the 'just one more thing' mob.
There is *always* something that can be optimised more or another
feature to add. You have exactly 2 choices:
1. Say "Fuck it!" and ship a Good Enough (tm) game and start work
on the next one (with all the cool ideas you didn't use).
or 2. Keep adding features and optimising code, then adjusting the
target market and re-optimising, and adding a few more features,
finding the code is too slow and optimising some more and ...

Someone once said "A movie is never finished, only abandoned".
The same goes for games.

---
Russ

[James David Chapman]

mig...@mightydrake.com (Drake Christensen) wrote:

>I've only read about half of this religous war thread. I do have two
>cents to toss in.

[Sorry I am replying yet again to my own thread, but this was such a
well though out bit of writing I had to respond].

>As Brandon pointed out, the differences between ASM and C are
>relative. In some cases one is "better" and in other cases the other
>is. That ignores whether the "worse" one was good enough. As Jerry
>Pournelle often piths, "Better is the enemy of Good Enough."

Heh heh, I know, I know, "If a job is worth doing it's worth doing
badly" It is a very true statement, but I also know that the time
consideration forces the issue towards C programming even when it is
not appropriate.

>For my contribution, I suggest looking at ALL of the tradeoffs.
>Here's an admittedly incomplete list:

> - Code speed
> - Code size
> - Pool of available programmers
> - Cost of said programmers
> - Time need by the team to implement the game (ie, release date)
> - Target performance for each piece of the game and the game as a
> whole
> - Time/cost to address make or break performance concerns late in the

> project (ie, exploring new algorithms)
> - Time/cost to take advantage of changes in the installed base (ex.
> 3D cards, and a few years ago modem->LAN and LAN->Internet)
> - Time/cost to take advantage of entirely new markets (consoles)

>From what I've seen in this thread, you're looking at the first two
>and discounting all of the others almost completely. To me, probably
>the most important is the performance targets.

Hmm, the thread title is "why isn't asm the game language of

choice" I now understand fully that, "time and money" are reasons for

some people, however, I note that given all the time in the world many
would still choose C, which is, in my opinion, [still!] wrong.

>Not all games need ASM. For example, one can write a fine card game

>or puzzle game in VB. VB might also work for most Myst-like adventure
>games.

Yes I am sorry, I have completely assumed demanding graphical games

and totally forgot the other types of game for the purposes of this
discussion.

>My favorite example in the ASM vs C/C++ war is Doom. It was written
>in 99+% cross-platform C with exactly two routines written in ASM.
>As-is, Doom was a huge success. Could it have been better?

If at the time of release, someone had come up with a version of the
game in asm, they could have had more monsters with the space they
saved for a start.

>The sweeping generalizations "ASM is better" or "ASM is dangerous" are
>basically nonsense phrases. There are too many variables for anyone
>to be that dogmatic.

Mmm, the generalisation to which you refer was a little more
specific than that, I contended that: asm is the better.. ..choice for
games programming.

This contention certainly *used* to be true. No-one can seriously

disagree with that. I started this thread because I see all this C
code knocking about and wonder whether it is *still* true, and the
games industry is wide of the mark.

James David Chapman.

[Matt Craighead]

<bigsnip>

Oh, what have I begun?

--
Matt Craighead
Utumno developer: http://www.citilink.com/~craighea/utumno/

[Russ Williams]

Kevin Kwan wrote in message ...
[...]

>> >Then what do you get? No sales. And despite all the gaming
>> >magazine's suggestions that everybody have a 3dfx and a P2,
>> >guess what, 65% of the home computers today are still 486s
>> >and Vanilla Pentiums, and the number is even higher in Asia
>> >and Europe.
>>
>> So, you'd advise us to spend months making our code work on
>> 486s, in the hopes that someone with no money to upgrade will
>> suddenly go out and spend $50 on a game? Not going to happen.
>> 486 owners tend to either not buy software, or buy $10 budget
>> games. It's very simple: The people with money for games have
>> money for hardware.
>
>That is also another very naive comment. The folks in 486s don't buy
>expensive software becuase their PC can't handle it.

They don't buy (much) software. Period.

>However, they do tend to buy software that works well for them...

There are many games that work well on 486s. I don't see them
selling particularly rapidly.

>Target audiences. And since if your game have a are installed
>player base, you are guaranteed a more steady customer base
>instead of the initial rise and then rapid fall. Take Doom, For
>example. If the folks at id did not make it possible for lower end
>386s to play with the 486 big boys, you think they'll actually still
>have customer today?

386s were current when Doom was released. id tend to support
lesser hardware, but they make almost all the profits off of the
high-end. They do Linux and SGI ports, too - that doesn't make
either commercially viable.

[...]

>I mean, if you think about it, more people are inclined to buy FS5
>than FS7, because they don't own P2-233s, they can't see the
>really large differences between the 2, and frankly, FS98s
>requires something that not alot of people can afford until it is older.

But when the hardware is older, so is the game. Very little money is
made on budget games. Almost all game sales are to people with
new hardware. It doesn't matter if the game will run on a 286, if 95%
of copies are run on P200MMXs or better.

[...]

>Once again, if you have no knowledge of Assembly and understand
>what some compilers will do to your code, you'll miss out.

But a knowledge of asm is considerably different to it being the
'language of choice'. I firmly believe that an understanding of asm
is necessary to writing fast code. Assembler itself isn't.

[...]

>> The view that humans will always be able to out-optimise compilers
>> is very naive[1]. A lot of optimisation is simple rule-following (for
>> pairing instructions, register usage, avoiding stalls, etc.), much like
>> chess. Sure, Kasparov can beat most computers, but almost
>> everyone else on the planet can be soundly beaten by a home PC
>> and a chess engine cranked up to max difficulty...
>
>Guess what, set rules and an imaginative humnan mind are never
>evenly matched.

True. That's the only way to consistently beat compilers.

[...]

> A Human mind still cannot be beaten when it compares itself to a
>pegboard of set rules. Maybe the compiler can step through and
>revise routines faster than a human can, but the human, with
>innovation, experience and a bit of time, will always ended up
>with cleaner code.

The point is that 99% of optimisation is rule following.
(1% inspiration, 99% perspiration seems to apply).

The compiler can't make the deductive leaps for that 1%, but:
i) It can certainly do the 'boring' bits for you - (near-)optimally
pairing up instructions, for example.
ii) Most of the inspiration can be communicated in the C. Often
when making a routine asm, we change what the code actually
*does*. If you go back and write C equivalent to the redesigned
asm, you're likely to find that the compiler can get pretty close
to what you came up with.

If you write C as a sort of 'portable asm' (simple, short instructions
that translate about 1:1 with asm), then you'll find that a good
compiler will produce very good quality code and it's still just as
portable :)

Besides, a compiler that can get within 10% of optimal on average
(e.g.: VC5) is more than enough reason to prefer C over asm. With
the 90-10 rule, that limits the potential benefit of writing the whole
thing in asm to about a 1% speedup.//

---
Russ

[Russ Williams]

James David Chapman wrote in message <6dkv0b$efu$1...@heliodor.xara.net>...

I think this says a fair bit about your coding experience. There's a hell
of a lot more to games than inner loops, menus and init routines.

---
Russ

[Thomas Womack]

Kalrithian <eem...@txdirect.net> wrote:

: Thomas Womack wrote in message <6djvgi$kie$9...@news.ox.ac.uk>...

Are you sure you've got that the right way round? If you can decompress at
20 instructions per byte, and you get 50% compression, you're beating even
a UDMA-33 hard drive by a substantial factor on a P200.

(load 8M : 2 seconds. Load 4M and decompress : 1 second to load, 0.4
seconds to decompress)

Tom

[Thomas Womack]

Kevin Kwan <kk...@acsu.buffalo.edu> wrote:
: > Kevin Kwan wrote in message ...

: Actually, I do development on DJGPP with Allegro (And yes, DJGPP does have

: Pentium Support, but you'll need to find the right patch for it)
: and I aso use Metrowerks Codewarrior Release 1 to do alot of
: cross-platform programming and Watcom 11 to do most of my Hybrid compiling
: if I'm forced to use DirectX in a game.

Watcom's supposed to be a very good compiler. DJGPP, even with patches, and
more so Codewarrior, aren't.

: That is also another very naive comment. The folks in 486s don't buy

: expensive software becuase their PC can't handle it.

The folks with 486s don't have second-hand P133 systems because they can't
fork out $500 for them. That's not a lot of games.

: then rapid fall. Take Doom, For example. If the folks at id did not make

: it possible for lower end 386s to play with the 486 big boys, you think
: they'll actually still have customer today?

They seem not to have lost too many customers with Quake 2 - which is decent
on this machine, very good once I finally got the 3d accelerator to kick in,
but runs like a turtle crawling backwards through treacle on a P90 which ran
Quake just about OK.

: Perhaps Civilization. Its ability to run from an 8086 to a Pentium 200 MMX
: guarantees immortality.

I bought Civ 2 and haven't touched Civilisation since ... I have a slight
prejudice towards games which use the ridiculous amount of processing power
I spent far too much on in September.

: Guess what, set rules and an imaginative humnan mind are never

: evenly matched. You can never perdict whether Gerry Kasparov will
: challenge Deep Blue again to win.

I'd be amazed if he did. Remember, Deep Blue is 'just' a suitably-
programmed RS/6K supercomputer with a few boards of custom logic; if
there's a million-dollar prize around, and if you can get tens of
millions of dollars worth of advertising out of the contest, you refab
the logic in a better process and wheel out a newer RS/6K box - and
suddenly Kasparov is facing a machine four times as fast.

Not that this makes it four times stronger, but it certainly adds a few
tens of points to its rating - and its rating is already close to
Kasparov's.

Tom

[Thomas Womack]

James David Chapman <jc...@nospam.globalnet.co.uk.I.said.NO.spam> wrote:
: Thomas Womack <mert...@sable.ox.ac.uk> wrote:

: >But CDs are cheap, and the cost of hard disc space is between three
: >and five pence a megabyte. Quake ][ is still really big, though; I
: >can't quite understand why the textures couldn't be stored on disc in
: >.GIF format.

: People have remarked on the size of disks and memory going up, and

: used it as justification for the "why bother?" style of coding. Well
: I'll tell you.... Unless you guys have the internet piped to your
: house via telepathy, you are going to have to have all that
: unoptimised data sent to you in 1k chucks.

This is now a problem in data compression - which is a reasonably
well-understood field. I quite like the idea of transmitting 8-bit
textures as a palette and a set of JPEG files to be decompressed,
reduced to the palette, and used as that, but I suspect you'll get
really unpleasant artefacts and horribly noticable dithering.

: A 5 hour download is a a major turn off to customers, and is just

: *another* way they end up paying for your programming practices.

You tend to *sell* games on CDs, at a pressing cost of perhaps as much
of 50p. For downloads, you remove great chunks of the textures and the
cut scenes, or (if you're Microsoft) have a form to fill in to get a
CD FedEx'd to the customer.

Tom

[Thomas Womack]

James David Chapman <jc...@nospam.globalnet.co.uk.I.said.NO.spam> wrote:

: "Carlos DaSilva" <cdas...@earthlink.net> wrote:

: >Exactly, although people like Russ and Mr. Shankel think of code complexity
: >in terms of "x" number of lines.

: I had a noticed the same thing. You can guarantee that any 3Mb exe
: file will have the complexity level of a blancmange.

Consider WinWord.exe. I'd hate to see your blancmanges if they
resemble that monstrosity in any way (it's 5M, compresses to 3M, which
is a decent measure of complexity).

Most serious
: coders have conceded that at the very least the inner game loops must
: be tiny asm, so what is in the rest of the code? It can't all be
: init routines and menus.

Consider the Doom source code. The inner loop is a texture mapping
routine in assembler, which is a small part of an 18k .C file. The
rest of the 1.3M of source sorts out the maps and does game logic; the
file to handle the behaviour of the *doors* is 16k of C, the enemy AI
is 40k of C ...

Graphics engines are tiny. AIs are big, collision detection routines
aren't small, ...

Tom

[Thomas Womack]

James David Chapman <jc...@nospam.globalnet.co.uk.I.said.NO.spam> wrote:

: mig...@mightydrake.com (Drake Christensen) wrote:

: >My favorite example in the ASM vs C/C++ war is Doom. It was written

: >in 99+% cross-platform C with exactly two routines written in ASM.
: >As-is, Doom was a huge success. Could it have been better?

: If at the time of release, someone had come up with a version of the
: game in asm, they could have had more monsters with the space they
: saved for a start.

There were no real space limits there; the game was distributed
*compressed*, and adding an extra dozen levels and four types of
monster would have only required an extra couple of floppy discs.

Space limits really don't exist for programs distributed on CD.

Tom

[James David Chapman]

"Mirkurius" <mirkuriu...@hotmail.com> wrote:

>I think it is safe to say that this poster is not taking hardware
>acceleration into account at all, and his argument is solely based on
>software renderers.

This is entirely correct of you to point out. I am aware of the
power of hardware acceleration, however, I certainly don't share the
hopes this group has for it's future, as it pertains to *game
programming* and that alone. (H/w acc has already proved its power
long ago in the days of Dos. I mean what was text mode, but a form of
video acceleration).

Software as a *concept* is a crucial part of a game, for, without
the scope for original game coding, [eg. of video routines] we will
not see original game play, just hardware adapted specifically for the
rigours of windows and quake, producing endless rehashes of the same
formats coded in the same way... Either that, or we will be doomed to
buying a new graphics accelerator for every new game we play, which
the customer base will not accept.

James David Chapman.

[James David Chapman]

I think its about time I *tried* to stop posting to this thread now,
I am repeating myself. However, I hope reading it gave you more than
just heartburn. I learnt a great deal btw, and will continue to read
the posts here and the rest of rgp.

To finish, I think quality coders will produce quality code in
whatever language they choose at a source, or algorithmic level, and
how fast that source eventually runs, and how optimised it is, depends
on how well the programmers understand the machine upon which they are
trying to run the code, (and sadly, the time limits they have to work
within). Thus far at least, it is *not* a language issue.

However it is a language issue when we each make our decision as to
where to draw the line between assembly and C in our own code. I hope
this thread has, at the very least, made you reassess your position in
this, no matter where you decided to stick.

Take care,

James David Chapman.

[William H. Ivey]

In <Pine.GSO.3.96.980304...@callisto.acsu.buffalo.edu>

Kevin Kwan <kk...@acsu.buffalo.edu> writes:
>
>> Really. Your PC assembly language code just runs on the Playstation
>>with only a recompile? I'm impressed.
>
>But then, Since when did you ever simply recompile a program for a
>different target platform and then everything will be hunky-dory?
>Also, show me one company that at least didn't use some assembly in
>their code that you'll have to rewrite?
>Now Who's being naive?

There's no assembly in our game, most of it would transfer directly
to another platform (assuming the platform has an available C++
compiler), and it runs so fast we never even took our copies of
MASM out of their boxes... (Which were bought in the first place
because of lobbying by a must-have-asm fanatic. I once worked on some
of his C code - he'd left a comment that it needed asm to speed it
up. Reworking a couple of loops sped it up 600% (yes, six hundred
percent).)

On an earlier project, some of the original asm library routines
were rewritten in C and ran faster.-Wm

[Robert Blum]

Louis Tremblay wrote:
>>Anybody *not* doing QTVR here? You're the fifth or so I see in a month.
>>Hope I'll ship first :-)
>
>You got 2 months... :)
I'm done next week :-)

Bye,
Robert

[Robert Blum]

Carlos DaSilva wrote:
>Exactly, although people like Russ and Mr. Shankel think of code complexity
>in terms of "x" number of lines.

That *is* *one* way to measure complexity, and I'm sure not the only one
they had in mind.

>space, memory, processor speed, etc. But they made their games work (and

>although Russ seems to think that those games, usually made in assembler or
>machine code, were much simpler to write than today's "finer" games, he
goes
>on to say that coding in assembler leads to many stupid errors. Conflicting
>logic there.)

I suggest subscribing to logic 101. Since they were less complex they could
be coded in assembly with a relatively small amount of errors. There's no
contradiction at all.

[snip-a-lot]
>Couldn't bear to snip it, makes good sense.
Wow, you're a great guy. If I wanted to read that nonsense again, I'd go to
DejaNews.

Bye,
Robert

[Jason Shankel]

James David Chapman wrote:

>
> "Carlos DaSilva" <cdas...@earthlink.net> wrote:
>
> >Exactly, although people like Russ and Mr. Shankel think of code complexity
> >in terms of "x" number of lines.
>

> I had a noticed the same thing. You can guarantee that any 3Mb exe

> file will have the complexity level of a blancmange. Most serious

> coders have conceded that at the very least the inner game loops must
> be tiny asm, so what is in the rest of the code? It can't all be
> init routines and menus.

Not tiny asm, fast asm. The speed requirements for the rest of the code
base are not as tight as those "inner loops". It has already been
conceded that a large assembly project would be "mostly" structured
assembly, which would not be optimally efficient.

Code size, for a PC title, is just not an issue. Even if C does add
significant bloat, it is not on our radar screen.

Console titles, now that's another story...

What is the "rest" of the code? Well, yes, init routines and menus.
Also game logic which takes an insignificant amount of time compared to
geometry sorting and software rasterization, even in C, resource
management, load/save game code, Windows setup code, application
framework, player management, session management, networking code,
physics models (some assembly required), console managers, user input
configuration, preference managers, world loaders, etc etc. Not much of
it called on a per-frame basis, not much justification is spending more
time on this stuff than necessary to make it solid and bug free. Why
steal time from optimizing those precious inner loops?

--
Jason Shankel,
Maxis, Inc.

s h a n k e l
at
p o b o x . c o m

[Jason Shankel]

Carlos DaSilva wrote:
>
> Russ Williams wrote in message <6djlaa$hce$2...@usenet40.supernews.com>...
> >Jason Shankel wrote in message <34FD04...@seesig.for.address>...
> >[...]
> >>But otherwise, your marketing department and your friendly
> >>neighborhood VP of Production are not likely to give you an
> >>extra six months on a project so you can get it 10% faster.
> >
> >With 6 extra months, I can think of better ways of getting at
> >least a 10% speed-up. Moore's law, for one ;)
> >
> >(6 months would get an average 26% speedup, just by
> >waiting).
>
> Wow, Russ, I didn't know your computer magically upgrades itself without
> intervention. Please share this technology with the rest of the world.
>

Doesn't matter, that same VP isn't going to give you six months no
matter what. By the "wait for Moore's Law" theory, you should never
ship, because you can always get a speed increase by waiting.

[Robert Blum]

Jason Shankel wrote:

>Doesn't matter, that same VP isn't going to give you six months no
>matter what. By the "wait for Moore's Law" theory, you should never
>ship, because you can always get a speed increase by waiting.

I know several games that follow exactly that strategy :-)
(Hearts of Darkness, anyone? :-)

Bye,
Robert

[Lim Kim Yong]

James David Chapman wrote:

> >The sweeping generalizations "ASM is better" or "ASM is dangerous" are
> >basically nonsense phrases. There are too many variables for anyone
> >to be that dogmatic.
>
> Mmm, the generalisation to which you refer was a little more
> specific than that, I contended that: asm is the better.. ..choice for
> games programming.
>
> This contention certainly *used* to be true. No-one can seriously
> disagree with that. I started this thread because I see all this C
> code knocking about and wonder whether it is *still* true, and the
> games industry is wide of the mark.
>

It's the Law of Diminishing Returns. Given that games nowadays
are significantly more complex and better hardware, it isn't as worth
that much effort to squeeze out 1 or 2 more fps. Furthermore, in
Win95, the drivers are optimised by the manufacturer, that basically
takes the need out for game programmers to take care of the
operations at assembly level.

Cheerio!.

[Sean Timarco Baggaley]

In article <6dku57$dpj$1...@heliodor.xara.net>, James David Chapman
<jc...@nospam.globalnet.co.uk.I.said.NO.spam> writes

>Sean Timarco Baggaley <stbag...@hotmail.com> wrote:
>
>>Pro-technology people are forever whining about how 100% pure ASM
>>(orwhatever) is so bloody important, but it's bullshit. It's the
>>*GAME *that's important. Code quality is secondary, since without a good game
>>for the coders to actually work on, all that effort it pointless.

> You can imagine any game you like, with all sorts of neat features,
>and gameplay, but without an engine, designed to run on a particular
>machine, you are just daydreaming.

But an engine on its own is nothing. Doom, without the gameplay, is just
a koderz demo.

And you don't *need* bleeding edge 100% assembly language to create a
decent game. None of the ones I own (aside from Descent 1) are even 3D,
let alone hardware accelerated. And you can do a tilemapped game on a
486 in 100% C and still have to frame-lock the damned thing to stop it
running too fast.

<TOTALLY IRRELEVANT RANT>

I'd like to see more emphasis on letting people who *hate* joysticks and
mice get into a game. Penalising keyboard uses is downright rude, since
many people can't stand the standard mice and joysticks that PCs come
with.

Quake forces you to use a joystick (and, ideally, a mouse *as well*)
which, as far as I -- and my siblings -- are concerned makes it way too
much hassle to play; certainly more than its worth. Descent, Doom and
Duke3D did not. That ID saw fit to force people to use ID's preferred
control method is, frankly, a classic example of poor design. User
interface is an integral part of the game design and it should be
*TRANSPARENT*. *NO ONE* has a right to dictate an arbitrary control
method just because *they* like it.

Descent still ranks as one of my favourite games since it allowed total
control via keyboard. Sure, there were a lot of controls, but nothing
like as many as in, say, a flight sim. Because of this, there's a whole
rake of games coming out that I will simply *never* touch. Ever. By
deliberately alienating keyboard users (and I'm sure a lot of one-time
Spectrum owners will agree with me on this), developers are only
shooting themselves in the foot.

</TOTALLY IRRELEVANT RANT>

> Doom didn't come about by people sitting around thinking about how
>neat it would be to frag people, it came about because someone worked
>out how to code the 'bloody' thing.

It's a 'techie' game. It's an engine game. But it *did* have some damned
good game design wrapped around it.

This is far more than can be said for Quake, which should have had
'Minimum requirements: 2 players / Recommended: High-bandwidth WAN with
plenty of servers and at least 16 players' written on the box. As a
single-player game design, it stinks. If they'd spent a bit of their
effort on the game design, Quake may well have been a classic. As it is,
it's merely a design of form over content. (Quake 2 may well be a better
game, but my rant, above, explains why I'll never bother with it.)

>>If I'm faced with a choice between spending a month optimising for a
>><10% increase or spending that same month getting the *gameplay* right,
>>I'd choose the latter every time.

> Phew. Every 10% increase in optimisation allows you to add more
>features to a game, thus improving the gameplay and commercial value.

Arbitrarily adding features will not automatically improve gameplay.
They have to be *designed* first. What you are proposing is the gaming
equivalent of 'bloatware' -- features for the sake of it.

Glenn's 'discovery' -- "Action Supercross" -- discussed in another
thread is a prime example of this. Arbitrarily making it 3D would make
it a *totally* different game, and improving the current graphics will
not change the gameplay in any way. This isn't to say that Action
Supercross cannot be improved, just that any such improvements need to
be carefully thought out and designed. Even making the physics modelling
more 'realistic' would fuck up the essential gameplay.

Even coding it in 100% pure assembly, would make absolutely no tangible
improvement -- it could even make it worse by ruining the 'feel' of the
game. Certainly, making it faster could well make it unplayable for many
potential buyers. But there is one, fairly major, flaw in the conceptual
design: the pricing.

(Yes, commercial considerations *are* a part of design; even the best
screenplays are created with a view to sales figures. After all, there's
no point coming up with an incredibly funny comedy like 'Father Ted'
(RIP) if nobody's ever likely to *see* it.)

*

Another prime example of this -- and one you may well bring up in
support of your own case -- is 'Tetris'. In particular: 'Tetris' on the
Nintendo Gameboy. The reason this was (and still is) such a successful
game is not merely the programming. The quality of the underlying
program (which was written in the Hitachi variation of Z80 assembly
language) is not the most important contributor; that role lies in the
hands of the design.

The difficulty curve is spot-on. The controls are simple and
uncluttered. The front-end design is clear and easy to follow; in fact,
it's almost ignored by most people and that is how it *should* be. Even
the two-player game is well thought out. Sound is also well-used;
providing useful cues for the player with aural feedback and rewards.

But it's important to remember that designer *must* include the features
of the hardware. A lot of Gameboy Tetris' success stems *directly* from
features of the hardware. It's simple, clear, easy to understand and
unintimidating -- a 'WalkMan' for the games industry. The buttons are
responsive and they're *digital*, not analogue -- an important point.
Networking is a piece of cake: just join two machines with a cable. No
installation; no network cards; no TCP/IP stacks or drivers.

Simple and intuitive.

And, contrary to the thrust of your argument, absolutely *NOTHING* to do
with what language was used to write the game.

Speed was simply not a factor; in fact, it had to allow for the high-
latency LCD used, so it coulnd't be made too fast.

And, when you consider what the machine is capable of, it's clear that
Tetris isn't a big enough game for the programmer(s) to have to worry
about squeezing down the size of the final program.

It could have been written in Modula-2 for all the difference it would
have made. Assembly was used, simply because it was the best tool for
the job. (If memory serves, it was also the *only* tool for the job;
Gameboy programmers didn't have any choice in the matter.)

>>It's a 'mark-up language' -- that's what the 'M' and 'L' in 'HTML' stand
>>for. Just because it ain't used for programming doesn't make it any less
>>a language.

>[So morse code with a bit of formatting is a language too?].

Noooo... read my words again. HTML is a *MARK-UP* language adapted from
SGML. It's an incredibly tiny subset of SGML, which, I can assure you,
is *fucking* scary stuff to look at; C++ has *nothing* on this. SGML is
a mark-up language that has been used in the printing industry for
years. It's not the same thing as Adobe's PostScript(tm), but serves a
similar function for some high-end typesetting tasks.

(It's somewhat closer in concept to the LaTEX/TEX languages used at
universities for creating maths textbooks with loads of weird and wacky
formulae and the like.)

Morse Code is an aural representation of the Roman Alphabet, much as
ASCII as a numeric one. It isn't formattable in any useful way as the
aural symbols are designed only to be combined into words. This process
is technically known as 'spelling'. It is not a language, merely a
representation of the components of a specific sub-set of languages.

I'd have thought this was common knowledge.

--
Sean Timarco Baggaley

<mailto:stim...@cix.co.uk>

E&OE

[Russ Williams]

Kevin Kwan wrote in message ...

>> Optimising takes time, which costs money. Making a
>> game run on machines less than your target platform
>> costs more money and there's no way to make it back.
>> Publishers aren't too happy about developers 'wasting
>> time' like that. After all, they're paying for it.
>
>What? And spent months patching a game that runs too
>slow after its initial release, thereby pissing off half the
>buyers??[...]

You seem to have completely misunderstood. If you're
writing a game for a target of a P166, and it runs well
on a P166, that's great. If you then start rewriting it in
asm to get it working on a P133, then you are wasting
time and money from the publisher's view. They are
going to get about 1% of sales on P133s so they are
not going to make the extra development costs back.

>> Just like a Linux port - nice, but it's going to lose money.
>
>Yes. But then with a Linux port, you're guaranateed to corner
>the entire market. Check out Quake...Who on Linux hasn't
>at least a copy of it?

Ports cost money. id isn't making a profit on Linux Quake.
They did it, at a loss, because they felt like it. Who gives
a damn about cornering a market that's too small to even
have shop space devoted to it? FFS, my local EB still has
a rack of Amiga games!

>At least id is smart enough to reach out to the 8%

8%? Linux has about 2% of the Pentium-class PC market
(a figure which will *not* grow significantly - Unix isn't a
consumer OS). I've never used Linux in my life, but I don't
doubt that I'm *two* of those 'users' that Linux advocates
like to quote...

---
Russ

[Kalrithian]

Thomas Womack wrote in message <6dl2p2$k2b$5...@news.ox.ac.uk>...
:: Reading uncompressed data also tends to be faster than compressed data,

:: especially if the OS is doing disk caching.
:
:Are you sure you've got that the right way round? If you can decompress at
:20 instructions per byte, and you get 50% compression, you're beating even
:a UDMA-33 hard drive by a substantial factor on a P200.
:
:(load 8M : 2 seconds. Load 4M and decompress : 1 second to load, 0.4
:seconds to decompress)
:
:Tom

:
:
:

I guess it depends on the compression technique used. For simple RLE image
encoding, compressed data is considerably faster than uncompressed data. But
graphics formats like JPEG are much slower to decompress than, say, an
uncompressed BMP.

ed

[Kalrithian]

William H. Ivey wrote in message <6dlcir$r...@sjx-ixn8.ix.netcom.com>...
:There's no assembly in our game, most of it would transfer directly

:to another platform (assuming the platform has an available C++
:compiler), and it runs so fast we never even took our copies of
:MASM out of their boxes... (Which were bought in the first place
:because of lobbying by a must-have-asm fanatic. I once worked on some
:of his C code - he'd left a comment that it needed asm to speed it
:up. Reworking a couple of loops sped it up 600% (yes, six hundred
:percent).)
:
:On an earlier project, some of the original asm library routines
:were rewritten in C and ran faster.-Wm

Which just goes to show that assembly is not inherently faster than C/C++,
any more than using octal constants generates faster code than using decimal
constants. C++ compilers nowadays are better than *most* assembly
programmers, and I think most here would agree that writing C++ code takes
*much* less time than equivalent assembly. C++ code can be recompiled across
platforms and architectures (even different members of a CPU family) with
little or no hassle. Assembly, OTOH, must basically be rewritten for every
new target. C++ code originally written for the 80386 can be optimized for
the Pentium-II with a quick recompile; 386-optimized assembly, OTOH, must be
rewritten to avoid Pentium stalls and to take advantage of changed opcode
timings. And forget about moving Intel assembly code to another chip ... or
even to a different assembler.

[Russ Williams]

Jason Shankel wrote in message <34FE6F...@seesig.for.address>...
[...]

>Doesn't matter, that same VP isn't going to give you six
>months no matter what. By the "wait for Moore's Law"
>theory, you should never ship, because you can always
>get a speed increase by waiting.

Of course. My point was just that with 6 months extra,
simply waiting would show a bigger improvement than
converting most of the C to asm...

---
Russ

[Kalrithian]

Kevin Kwan wrote in message ...

:It's the lack of viable alternatives that piss them
:off. And trust me, many still use Allegro for DJGPP for serious game
:programming, sprinkled with ASMs now and then.

And why are there no commercial titles developed on DJGPP+Allegro?

1) DJGPP+Allegro's offerings are rather pathetic compared to Win32+DirectX
(no graphics/sound acceleration, multitasking/threading, etc.)
2) DJGPP only generates 486 code.
3) go32 is worse when it comes to compatibility than even Watcom DOS/4GW.
(Try running DOS Quake under NT and you'll see what I mean.)
4) The debuggers that come with DJGPP are pure crap, especially for
graphical apps. Worse yet, try debugging an app with a keyboard ISR ...
5) You've got to write all your own sound and video code yourself, which is
I guess is A Good Thing(tm) if you're a DOS Koder(tm). (You even get to do
it using AT&T assembly, which is an even better way to show how manly you
are.)
6) VESA is crap.

Quake is the only *real* game I know of that was done in DJGPP, and AFAIK,
id has moved on to Win32 for good.

:And once again, discussing
:which platforms to develop to is still a major part of game development,
:and this newsgroup does not always seriously deal with issues in game
:development.
Of course we don't deal with serious issues. Instead, we choose to debate
endlessly on stupid things like whether we should devolve into all-assembly
programmers.

:It is often used as a place to flame newbies or curse people with ideas
:that are different than yours. Whatever happened to tact and etiqette?
Uhhh, AFAIK, USENET has never boasted having either.

:
: :)kev
:

[Kalrithian]

Avery Lee wrote in message <35001049...@news.ucsb.edu>...
:It is true that C compilers still don't generate code comparable to
:hand-optimized x86 assembly.
Really? Last time I checked, Watcom (and now Visual C++) was beating most
assembly programmers by a fair margin ...

:Not even close, especially in audio and video processing.
Of course, those of us who moved to Windows don't need to fret about this
kind of thing anymore. [Please refrain from starting a DOS vs. Windows
flamewar over the previous statement. I apologize in advance for any injured
egos.]

[Kalrithian]

Kevin Kwan wrote in message ...

:Actually, I do development on DJGPP with Allegro (And yes, DJGPP does have

:Pentium Support, but you'll need to find the right patch for it)

Last time I checked, the Pentium patch for gcc didn't work.

:So? It has also been proven that certain coding styles in C and C++ will
:generate fatter code. Perhaps the author understand what certain coding
:styles will do when a compiler interprets them will do, and avoids C code
:that promotes code growth. Once again, if you have no knowledge of

:Assembly and understand what some compilers will do to your code, you'll
:miss out.

Know your compiler. If you're a good assembly programmer (I'm assuming you
are), you should look at disassembled code generated by your compiler. This
is *much* less time-consuming than writing it all yourself in assembly.

:Guess what, set rules and an imaginative humnan mind are never

:evenly matched. You can never perdict whether Gerry Kasparov will

:challenge Deep Blue again to win. And guess what, Compiler technology are
:not exactly up to the point of Deep Blue's expertise in chess, and on a
:home PC, while waiting minutes for the computer to run through its AI to
:choose a correct move is acceptable, having the compiler spend hours on a
:program to generate code that can beat hand-optimized assembly is just
:wrong. (and trust me, that can't be done on a Pentium...In order for a
:compiler to make code this clean, it'll take days)
I seriously doubt that statement. A compiler is nothing more than a
sophisticated AI engine that uses a large set of rules to choose the
smallest/fastest instructions to resolve a particular problem. Given the
right set of rules, a compiler will beat a human coder hands-down ... and in
*much* less time. (There aren't many assembly programmers out there that are
the equivalent of Kasparov, either...)

: A Human mind still cannot be beaten when it compares itself to a

:pegboard of set rules. Maybe the compiler can step through and
:revise routines faster than a human can, but the human, with innovation,
:experience and a bit of time, will always ended up with cleaner code.

Really? And I suppose you think you can square ten-digit numbers or
integrate in your head faster than a Pentium? Humans are 'creative', yes,
but computers are much better at following rules.

:Yeah, but VC5 probarbly also offer many features that'll drag the benefit
:of an efficent compiler to a moot point.
Such as ... ?

:
: :)kev
:

[Robert Blum]

Avery Lee wrote:

>"Kalrithian" <eem...@txdirect.net> wrote:
>>Avery Lee wrote in message <35001049...@news.ucsb.edu>...
>>:It is true that C compilers still don't generate code comparable to
>>:hand-optimized x86 assembly.
>>Really? Last time I checked, Watcom (and now Visual C++) was beating most
>>assembly programmers by a fair margin ...
>

>On a Pentium Pro or Pentium II, maybe. On a Pentium, I doubt it. Not a
>chance on MMX applications.
Agreed on the MMX part. Float is also an area where you can win a lot by
cleverly interleaving and better FPU stack usage.

>If there's a way to exploit the carry flag in
>the computations, the asm programmer will probably win unless the compiler
>can do so as part of an intrinsic function.
True again. One of the *very* few exceptions and is only useable in a inner
loop that's out of registers.

>Huh? No driver support in Win32? Gee, what a surprise. Now try and find
>a C compiler that will schedule all the shifts and LEAs for the formula
>Y=(54*R+183*G+19*B)/256 to process a 32-bit xRGB pixel to grayscale in 18
>cycles or less on a non-MMX Pentium. If you find one, I'll be impressed.
>
>VC++ 4.0, which I use, is an old compiler, but I don't think they've
>improved it enough since to surpass the 200%+ speed increases in AVI frame
>processing I get from rewriting choice routines in asm.
Well, I wrote it in a way that actually *describes* what the compiler has to
do. Written the way you did it above, you have to first load R,G,B into
variables. Anyway, my line of code was:

y=(54*((dwPixel>>16)&0xff)+183*((dwPixel>>8)&0xff)+19*(dwPixel&0xff))/256;

And VC++ 5.0 produced the code at the bottom. At a first glance, it is
*very* close to 18 cycles and perhaps even under. I didn't count them. It's
19 simple instructions, and many interleave well. If it's more than 18
cycles, it's probably in the 18..22 range. So you'd get *at most*, if you
were only running this code, a 25% speedup.

Seems pretty impressive to me. VC++ 5.0 is really quite capable when it's
about integer optimizations.

Bye,
Robert

00401073 mov ecx,dword ptr [esp+8]
00401077 add esp,8
0040107A mov eax,ecx
0040107C and eax,0FFh
00401081 lea edx,dword ptr [eax+eax*8]
00401084 lea edx,dword ptr [eax+edx*2]
00401087 xor eax,eax
00401089 mov al,ch
0040108B lea ecx,dword ptr [eax+eax*2]
0040108E lea ecx,dword ptr [ecx+ecx*4]
00401091 lea eax,dword ptr [eax+ecx*4]
00401094 lea eax,dword ptr [eax+eax*2]
00401097 add edx,eax
00401099 xor eax,eax
0040109B mov al,byte ptr [esp+2]
0040109F lea eax,dword ptr [eax+eax*2]
004010A2 lea ecx,dword ptr [eax+eax*8]
004010A5 lea edx,dword ptr [edx+ecx*2]
004010A8 shr edx,8

[Sean Timarco Baggaley]

In article <Pine.GSO.3.96.980304161628.3663C-
100...@xena.acsu.buffalo.edu>, Kevin Kwan <kk...@acsu.buffalo.edu>
writes
>Well, I agree with you totally.

I suppose somebody has to. Doesn't make either of you right, though.

> It is very easy for a programmer to be
>veiled by the "relative ease" of programming in Common SDKs and Midlevel
~~~~~~~~~~~~~
As opposed to the "utter impossibility" of performing the same tasks in
DOS? Let's go through this one last time: Most new hardware accelerators
are *ONLY* accessible through APIs. Since custom APIs are *EXCLUSIVE*,
it makes far more sense to go for a standardised API. Riva128 cards
*ONLY* work through APIs -- there are *NO* hardware specs available for
them. The folks behind the PowerVR chips are also moving towards
releasing drivers.

Nobody's claiming life is perfect, but forcing technology to remain
static solely because it makes *your* life easier is not the answer.
Remember, 90% of computer owners happen to be *CORPORATIONS*. They don't
buy their PCs to play games on. Games players make up only a tiny number
of PC sales, so statistics like these...

>And despite all the gaming magazine's
>suggestions that everybody have a 3dfx and a P2, guess what, 65% of the
>home computers today are still 486s and Vanilla Pentiums, and the number
>is even higher in Asia and Europe.

... are irrelevant, since 90% of those PCs are owned by big businesses.
A 486 DX2/66 is plenty fast enough to run many low-level applications --
I even had Win95 and Office 95 running happily on my one (until the
monitor died, sending 20000 volts through the graphics card).

For basic secretarial tasks, 486s and low-end Pentiums are more than
adequate, and many of these are simply migrated down from other
departments as they upgrade. The main reasons for upgrading at this
level, for a lot of corporates, are simple wear and tear, and the
diminishing returns of maintenance. (After a certain period, it becomes
almost impossible to find spares; like MCA cards for old PS/2 machines
and VESA/LB video cards).

Of that remaining 10% of PC buyers, most are used for SOHO work (a
rapidly expanding market sector). Others are bought for 'real' family
use (my sister and brothers have an Apple Mac LC III for their
school/university work. It's ancient, but it runs ClarisWorks without
any hiccups.)

At best, only about 1% of total PC sales can be attributed to the
hardcore gamers.

All those advances in technology -- and the continual upgrading -- is
*directly* attributable to mainstream application users. Desktop
publishing -- which has brought a lot of media work in-house -- becomes
more economical when done on faster computers. Creating and/or sourcing
graphics for publications, packaging design and even on-line media and
PR departments is common in large businesses. Images used for
publication are often tens of megabytes in size, so faster CPUs, more
memory and bigger hard drives are very popular for these tasks. Images
can be scanned; drawn by hand; created on 3D renderers...

Even those ludicrously expensive 3D packages we use in the games
industry are generally extensions to those used by other industries for
product design. (AutoCAD begat 3D Studio, for instance.)

>the code written by any compiler, no matter how good or how new it is,
>frankly sucks when you compare it to hand optimized assembly code.

This isn't the case with pro-quality compilers. Of course, if your
experiences are based on DJGPP/GNU and similar quality compilers, then
your reasoning makes more sense, but MS' Visual C++ 5 and Watcom's
compilers are to gcc what Rolls-Royce is to Skoda. Sure, they cost more,
but you get what you pay for.

>And in an industry in which game engine is fundemental,

I've answered this fallacy (or should that be 'phallusy'? :) in a
separate post. In brief: *game design* is fundamental; the game engine
is secondary to that. Games programming is merely the means to an end.
It is not an end in itself.

[...]
>(You have NO idea how C++ compilers actually did a bad job in
> optimizing Pentium code, sometimes causing Pipeline stalls for the
>sake of utilizing the V-Pipe in a couple of MOV instructions...and in
>the Superscalar Pentium, that's a major headache)

Actually, we do. Who do you think you're arguing with? Newbies? Uh-uh.
Unlike you, however, we don't tend to tar every compiler with the same
brush: those fuck-ups you mention only happen on *shite* compilers. Why
do you think development suites like Visual C++ and Watcom/Optima cost
so much?

What do you think all those coders of yesteryear are *doing* these days?
That's right! Writing games! When you talk about how coders squeezing
great games into 32K of RAM, don't forget that some of us *WERE* those
coders. Glenn Corpes (of Bullfrog), for instance, used to write in "100%
pure ASM(tm)" on Atari's ST and Commodore's Amiga. I started out on the
Sinclair Spectrum (and also did some Atari stuff), and there are other
veterans posting here. The reason we don't do it any more is because it
just isn't necessary. Even the lowest, cheapest, shoddiest second-hand
8Mb P60 PC for sale at £150.00 at the local computer fair is more than
capable of running PacMan while multi-tasking with MS Office in Win95.

And yes, current games *are* more complex. Command & Conquer is orders
of magnitude more complex than, say, Rebelstar Raiders or Laser Squad.
This increased complexity puts a lot of people off, especially those who
enjoyed those older, simpler, more immediate games. But the depth of
more recent games certainly appeals to others. It's a trend -- a fashion
-- and as such, it will change. (Remember the flood of puzzle games that
got released to fight over the Tetris market?)

>game like iF-16 to choke on my computer, while the graphically superior
>Novalogic F-22 Lightning can run better on a computer that is 35%
>slower.

This is to do with programming *quality*. The choice of overall language
is irrelevant, since 99% of the game will be spent in only 1% of the
code. As long as that 1% of code is optimal (and you *can* optimise C
and C++ if you know what you're doing), that 1% will run damned fast. As
someone else pointed out in this thread: it's the algorithm that's
slowing things down. Get the algorithm spot-on and you're made.

I'm surprised by your choice of a NovaLogic game to illustrate your
argument. Firstly, they like using Voxel Space instead of polygonal 3D,
so their engine isn't even remotely comparable. Voxel space tech isn't
particularly flexible, as you can see from NovaLogic's output since they
released Comanche.

Novalogic are one of the few companies still insisting on 100% pure
assembly for their game engines, but you'll notice that they seem to be
following a rather predictable pattern: "Flight Sim -> Tank Sim -> New
Iteration of Engine -> Flight Sim -> Tank Sim ... etc." Hardly
innovative or original games. What's more, NovaLogic are taking a damned
long time between each release... coincidence? I think not.

Bullfrog, on the other hand, seem to churn out original game after
original game (barring the occasional sequel). And they're averaging at
least one product a year. Sadly, NovaLogic's games all look the same
and, er, play very similarly. Extreme Assault (BlueByte) was a far
better game -- and it runs great even on my own, pre-MMX, unaccelerated
P166.

> Of course, ultimately, many users will get so fed up with the
>lack of feeling of responsiveness on a game even with its super-duper
>features on the fastest possible machine that either they'll jump ship
>to console games (The mass migration to the playstation, which have
>roughly the firepower of a P90 with a Virge VX card and some zippy DSPs
>attached, already made some PC games manufacturers uncomfortable), play
>older and more proven games (Emulators, games from 1994-5) or are
>forced to buy games with less features (or don't enable them) to play
>them on their PCs.

Er, what makes you think that a feeling of responsiveness is the be-all
and end-all of a game? Myst isn't exactly a hi-octane shooter, is it?
Did rather better than Quake, though. (And, if memory serves, it was
written in Macromedia's Director package.)

As for PlayStation: you do know that programs are written for it *IN C*!
Granted, it's not *great* C, since it's only a cacky GNU compiler, but
that's not important: the hardware does all the work! That's why we
*need* hardware acceleration on the PC: it frees up the CPU (and the
programmers) from continually re-inventing the same damned wheel.

Why should flight sim programmers have to keep writing new 3D engines?
Why not just use a scalable engine 'off the shelf' (like D3D, OpenGL or
Fahrenheit) and concentrate on making a great game?

By leaving the development of the 3D engine in the hands of dedicated
specialists, you can simply write your game to that and it will -- if
written *properly* -- automatically take advantage of newer, improved
hardware. This will also have the side-effect of allowing future owners
of 'legacy' PCs (with "ancient Voodoo 1 chipsets and a mere 32Mb RAM!")
to last longer, since you won't have to keep swapping out CPUs and stuff
all the time: just upgrade to the next version of the graphics card. It
won't cure the Moore's Law Effect entirely, but it should alleviate it
by shifting the emphasis from CPUs to peripherals.

>Anyway, what I'm saying is, despite the propaganda Intel continues to toss
>around saying that you're less than human if you don't have a Pentium, and
>then you're pond scum unless you have MMX, and you're a dung beetle if
>your PC is not a P2, when you look at the way the PC is organized, the CPU
>actually spend a lot of time waiting for other components to respond, and
>the CPU still are not as powerful as some programmers would like,

Speak for yourself. If I want fast 3D, I'll buy a 3D accelerator -- much
cheaper than buying a faster Pentium (or ripping out the motherboard and
getting a PII). Then I'll just call a suitable API and have done with
it. It's only fucking display code, after all. It's not like we're
talking about brand-new, earthshattering advances in programming
technology.

Technically, Quake doesn't even do anything original -- all of those
techniques can be got out of books like Screen Gems and their ilk. The
only reason Quake can be done today is because we have the computing
power and hardware to handle it. You can't do 256-colour, light-sourced,
gouraud-shaded texture-mapped polygons on a Commodore C64 because it
cannot even *display* 256 colours. (And with only a 1Mhz 8-bit CPU,
you'd be waiting all day for it to render a single frame.)

> and in certain critical routines, You'll still have to drop to NASM to
>do a little creative Assembly to code certain routinesto make them play
>better.

NASM? If your compiler experience consists of DJGPP, it's not surprising
you've got such a dim view of computer-assisted optimisation. ('CAO'!
New Labour: New Acronym!)

DJGPP is fine for hobbyist work, but it's waaaayyyy behind the times.
It's simply nowhere near as good as the likes of Watcom, Borland and
Microsoft's C/C++ compilers. (If you're a student, you can get a major
discount on some of these, BTW.)

>Often, the newest features, the newest technology and the best graphics
>does not automatically guarantee sales, It's gameplay and editability.

"Editability"? Do all games players have to want to do the level
designer's job for them? When I buy a game, I don't expect to have to
create my own damned levels as well -- not for *that* sort of money.
(ID, please take note.)

>Who cares about the 16 bit bitmapping, the super-duper realtime
>campaign engine, the superduper AI, or thousand polygon bitmapped
>meshes if it only runs at 9 fps on an average Joe's PC, even if the
>features are turned off?

Eh? You can't *have* 16-bit mipmaps if you're running in "I've got a
shite PC" mode. At least, not on the games I've played. Exactly how
would you get 65000+ colours on a 256 colour palettised display?

The simple fact is that many complainants simply don't *want* to turn
off those features. Unfortunately, there's not a lot anyone can do.
Quake 2 simply isn't possible on a 386.

This is *exactly* the same attitude that killed off the Commodore Amiga
and Atari ST. (In fact, it was the Atari Falcon that snapped *me* out of
it; my platform game ran at 72fps! Faster than Sonic! Played better,
too. But by then, PCs were beginning to come into their own so I jumped
straight over to those.)

>Anyway, I totally agree that Assembly should be an option in the arsenal
>of a game programmer, and as a disciple of Michael Abrash, I totally agree
>with him on the fact that, as long as Compilers cannot reach the level of
>sophisication as the compiler between your ears, Assembly will never be
>obsolete.

Nobody has claimed that it is. It's just not as necessary as you
suggest.

*

It is, incidentally, considered bad form to quote an entire post.
DejaNews exists for a reason, and selective quotation is more than
adequate for continuity.

[Major snipposity]

[Jason Shankel]

Ah, gotcha. I misunderstood you.
Anyway, this thread is about to break down into a religious flame fest
(just like it always does). But before we completely lose sight of the
topic, I'd like to answer the original question.

The original question, which was fairly well put, was "Why isn't ASM the
game language of choice?"

The answer, ultimately, is that the cost/benefit analysis doesn't play
out in ASM's favor. For the majority of code in a project, cost of
spending extra months of development time and sacrificing portability
and maintainability do not justify the benefit of a small speed increase
and a small size decrease.

For a critical, crucial, sine qua non, no getting around it, without it
you have no game minority of the code, the benefit of even a slight
speed increase is often worth the cost of using ASM. In these cases,
still, you write your first version in C and you keep your optimized ASM
algorithms up to date in C code, for portability and readability.

As professionals, we cannot afford to be language bigots or to entrench
ourselves too firmly in religiousity. You need to be able to identify
the right tool for the job and to know when to apply those tools.

Code size and execution speed are always important, but they are not the
only priorities.

--
Jason Shankel,
Maxis, Inc.

email provider: p o b o x . c o m
user id: s h a n k e l
Good luck with that one, spambots.

[Rick Genter]

Russ Williams wrote in message <6dkrpm$u$1...@usenet40.supernews.com>...

>Just like DOS apps run 50-80% slower in Windows? Even if the
>Riva128 is 3-4x slower than it could be, that makes it *scalable*
>(upgrade to a P2-450 and it just gets faster...). It's still one of the
>fastest consumer 3d cards available. (Anyone know if the
>Voodoo 2 is faster?)

Yes, the Voodoo 2 is much faster than the Riva128.

--
Rick Genter
VP, R&D
5D Games, Inc.
<mailto:rge...@5dgames.com>
<http://www.5dgames.com>
ICQ UIN# 8291497

[Rick Genter]

Kevin Kwan wrote in message ...

>> >>Code reuse
>> >
>> > I have *never* had *any* problem with code reuse in asm. Both
>> >languages can be written out well for other people to read, both can
>> >be written out terribly badly. People are put off learning Asm
>> >because assemblers don't come with a huge library of routines, you
>> >have to write them yourself, but once you have them, asm and c look
>> >very similar to program, and one *is* faster.

>>
>>
>> Really. Your PC assembly language code just runs on the Playstation with
>> only a recompile? I'm impressed.
>
>But then, Since when did you ever simply recompile a program for a
>different target platform and then everything will be hunky-dory?
>Also, show me one company that at least didn't use some assembly in their
>code that you'll have to rewrite?
>Now Who's being naive?

I do it all the time. It's called Professional Software Engineering. If you
know how to code portably, and understand what constructs work well, you can
write portable, efficient code. Ask the guys at id.

As far as the "some assembly in their code", I thought you were arguing for
100% assembly. Don't change the subject.

[Rick Genter]

James David Chapman wrote in message <6dkthe$cnq$1...@heliodor.xara.net>...

>Thomas Womack <mert...@sable.ox.ac.uk> wrote:
>
>
>>But CDs are cheap, and the cost of hard disc space is between three
>>and five pence a megabyte. Quake ][ is still really big, though; I
>>can't quite understand why the textures couldn't be stored on disc in
>>.GIF format.
>

> I agree, much of what I see in this whole thread, is justification
>for lazy coding.

There's a difference between lazy coding and understanding the point of
diminishing returns.

[Rick Genter]

>id do things a little different to the rest of us. They keep doing the
>same game with just new technology (even Carmack admits this).
>Therefore, Doom probably did start with an engine. An engine
>which is about 5% asm, BTW...

Doom was far less than 5% asm. I used to work at Papyrus, and Papyrus was
considered (at one point) for porting Doom to the Macintosh. According to an
email from John Carmack, there were 3 assembly language functions:

horizontal texture map
vertical stretch
a joystick reading routine

The rest of Doom was in C. Check out the Doom sources at ftp.idsoftware.com.

[Klaus.S...@home.ivm.de]

>
> Re: Why isn't ASM the game language of choice?

>
>Kevin Kwan wrote in message ...

>>> Optimising takes time, which costs money. Making a
>>> game run on machines less than your target platform
>>> costs more money and there's no way to make it back.
>>> Publishers aren't too happy about developers 'wasting
>>> time' like that. After all, they're paying for it.

No one is paying me for anything I code.

>>
>>What? And spent months patching a game that runs too
>>slow after its initial release, thereby pissing off half the
>>buyers??[...]

No one is forced to pay me anything, and everyone may patch it himself.

>
>You seem to have completely misunderstood. If you're
>writing a game for a target of a P166, and it runs well
>on a P166, that's great. If you then start rewriting it in
>asm to get it working on a P133, then you are wasting
>time and money from the publisher's view. They are
>going to get about 1% of sales on P133s so they are
>not going to make the extra development costs back.
>
>>> Just like a Linux port - nice, but it's going to lose money.

I simply write natively for Linux, but everyone is allowed to port it.
And it's only my money that goes lost.

>>
>>Yes. But then with a Linux port, you're guaranateed to corner
>>the entire market. Check out Quake...Who on Linux hasn't
>>at least a copy of it?

I don't have a copy of quake, because I stick to software that is freely modi-
fiable, like GNU- or BSD stuffs.

>
>Ports cost money. id isn't making a profit on Linux Quake.
>They did it, at a loss, because they felt like it. Who gives
>a damn about cornering a market that's too small to even
>have shop space devoted to it? FFS, my local EB still has
>a rack of Amiga games!

I'm not interested in the monetary aspects of programming.

>
>>At least id is smart enough to reach out to the 8%
>
>8%? Linux has about 2% of the Pentium-class PC market
>(a figure which will *not* grow significantly - Unix isn't a
>consumer OS). I've never used Linux in my life, but I don't
>doubt that I'm *two* of those 'users' that Linux advocates
>like to quote...

It's a question of quality, not quantity.

Klaus Schilling

[Glenn Corpes]

jc...@nospam.globalnet.co.uk.I.said.NO.spam (James David Chapman) wrote:

> Thomas Womack <mert...@sable.ox.ac.uk> wrote:
>
>
> >But CDs are cheap, and the cost of hard disc space is between three
> >and five pence a megabyte. Quake ][ is still really big, though; I
> >can't quite understand why the textures couldn't be stored on disc in
> >.GIF format.
>
> I agree, much of what I see in this whole thread, is justification
> for lazy coding.
>

> People have remarked on the size of disks and memory going up, and
> used it as justification for the "why bother?" style of coding. Well
> I'll tell you.... Unless you guys have the internet piped to your
> house via telepathy, you are going to have to have all that
> unoptimised data sent to you in 1k chucks.
>
> A 5 hour download is a a major turn off to customers, and is just
> *another* way they end up paying for your programming practices.

Most of that five hours would be spent downloading graphics and sound,
even if assembler could halve the size of the <200k of actual code
(which
it couldn't) it wouldn't save any significant time

-=< gco...@ea.com, Project Leader Bullfrog >=-

Like the idea of a spam
free alternative to usenet?
take a look at CIX conferencing
http://www.compulink.co.uk/servicesf.html

[Glenn Corpes]

jc...@nospam.globalnet.co.uk.I.said.NO.spam (James David Chapman) wrote:

> Sean Timarco Baggaley <stbag...@hotmail.com> wrote:
>
> >Pro-technology people are forever whining about how 100% pure ASM
> >(orwhatever) is so bloody important, but it's bullshit. It's the
> >*GAME *that's important. Code quality is secondary, since without a
goo
> d game
> >for the coders to actually work on, all that effort it pointless.
>
>
> You can imagine any game you like, with all sorts of neat features,
> and gameplay, but without an engine, designed to run on a particular
> machine, you are just daydreaming.
>

> Doom didn't come about by people sitting around thinking about how
> neat it would be to frag people, it came about because someone worked
> out how to code the 'bloody' thing.

ISTR that Doom had two assembly routines in the whole game, one for
drawing vertical scans and one for horizontal (and probably some more
for
sound mixing but i'll bet they just bought those in from outside) QED.

[Glenn Corpes]

jc...@nospam.globalnet.co.uk.I.said.NO.spam (James David Chapman) wrote:
>

> >The point is that even if all of the C code were magically
transformed
> >so it executed instantaneously, you would only notice a 0.5% speedup.
> >It is simply not worth spending even a microsecond, much less the>
>additional MONTHS pure asm implies, to chase that kind of negligible
> >improvement. That time is better spend focusing on making your C
code
> >readable, portable and maintainable and making your assembly fast.
>
>
> Hmmm, you're being a bit naughty here. Some people in this
> newsgroup are pretending that an *entire* game project can be coded in
> C,

A hardware accelerated game can run at 99.5% full speed in pure C

> and still be the fastest it can possibly be. Even your mixture of
> C and asm does not address a fundamental issue I raised... where are

A partially assembler game can be at 99.5% of full speed.

> the newbies in this group going to get their asm skills from if they
> program in C most of the time?

Good point. I don't have a good answer for this, they need to write a
little, examine the output of C compilers in debuggers and stuff, what
they don't need is to drop C.

>
>
> >> >1. DirectX/OpenGL
> >>
> >> Is not really the issue here, it may be a big thing in the world
of
> >> windows, but assembly programmers have had full video control for
> >> years.
> >>
>
> >You cannot get such access to 3d hardware in any other way. You
simply
> >do not have the option of register programming these cards, you must
us
> e
> >an API.
>
>
> Hardware manufacturers will soon learn not to keep their internal
> specs to themselves.

Even if they do give you access you won't have time after debugging all
of
that assembler in your save game routine.

[...]
> >Executable size, for example, is now MUCH less of an issue than it
was
> >even a few years ago. When modern games require 16-32 megs to run, a
3
> >meg executable size is not even considered a factor.
>
> IT SHOULD BE.
>
> This is *precisely* what I am talking about. The reason I mentioned
> coders of the past, was because they did care. They could not stop

I used pure assembler for years because C compilers were shit at the
time
(all variables on the stack for example) and it was worth saving that
one
off 50k hit for using C when you only had 512k of RAM on an ST/Amiga,
people used assembler on 8 bit machines because it was 100+ times faster
than basic (you would have loved it back in the early eighties).

> themselves from optimising because it was the only way to add new
> features to the game. It still is! Are you really saying that you
> could not use an extra 2Mb of data area for graphics or sound? I sure
> could.

the largest code (not executable) size i've ever seen on a game is about
200k, if C wasted 50% of that memory (it doesn't, most of it wastes
nothing) the most you would save is 100k, that's 1/20th of what you are
talking about.

>
>
> >Execution speed for outer loop functions is less of a critical issue.
>
> I am happy to agree with this again.
>
>
>
> >But high level languages provide adequate speed for anything which
> >doesn't have to be rip-roaring fast.
>
> I can't think what doesn't have to be rip roaring fast in a game.
> Init routines have been mentioned, menus, maybe, if they are not
> displayed by the game engine itself, everything else is inside some
> kind of loop, so you'd better be careful.

How about some 'typical' game code like this, I know exactly (with the
exception of register usage) what a good C compiler will do with this.

struct Missile
{
int x;
int y;
int vx;
int vy;
};

Missile missiles[NO_MISSILES];

move_missiles()
{
Missile* misptr = missiles;
for(count = NO_MISSILES; count>0; misptr++, count--)
{
misptr->x += misptr->vx;
misptr->y += misptr->vy;
colide_check(misptr);
}
}

How would you do this in assembler?, no changing the algorithm BTW, I
know
it's shit.

> Surely this attitude you have: "It doesn't matter how large the exe
> is/almost all the code is non-time crucial", is linked to the reason
> why people have to upgrade their computers every year? Surely you can
> see that? :)

No, that's linked to the fact that texture mappers use between five and
eight instructions per pixel while sprite draws often used less than
one,
that 640*480 has 4.8 times the pixels of 320*200, that 3D games are
using
10 times the geometry...

>
> And surely you can see that, from my point of view, the number of
> routines which are 'allowed' to be large and slow is increasing every

Not large and not slow, unless the programmer is using C as if it was
basic, maybe some do, it's not C's fault.

[Glenn Corpes]

jc...@nospam.globalnet.co.uk.I.said.NO.spam (James David Chapman) wrote:

> Keith Elder <el...@cdsnet.ihatespam.net> wrote:
>
> >James David Chapman wrote:
> >>
> >>
> >> A few people have compared early pac man with the modern games we
> >> see today, and laughed. Yet I have no doubt the original pac man
> >> *was* as complex as the game engines of today. Just think about
it..
> .
> >> Were the programmers of then less clever than us? Why didn't they
> >> come up with DOOM? The answer is of course simple, they were
packin
> g
> >> features into machines which were too small, and running amazing
> >> routines on processors which were too slow.
>
>
> >I agree wholeheartedly. I have a hard time trusting any programmer
who
> >has not paid their dues crafting an assembly game on a commodore 64,
or
> >apple ][, or any other 8 bit platform. My brother wrote and sold a
ver
> y
> >fast game he wrote for a VIC-20 that he wrote in machine language.
> >Note: Not assembly, I mean _machine_language_!
>
>
> Heh heh, when I am feeling particularly masochistic I have been
> known to program 'the numbers' myself. [This will surprise no-one
> here].

And so you should, it's faster, some assemblers take away control and
you
can never be 100% sure what they are generating, go get that control
back!

-=< gco...@ea.com Project leader, Bullfrog >=-