FIRAXIS is hiring!
Joel Munday
DarkHalf wrote:
> On Wed, 14 Apr 1999 02:51:06 GMT, brey...@firaxis.com (Brian
> Reynolds) wrote:
>
> >Hi All,
> >
> >Ever thought of making these games for a living?
> >
> >FIRAXIS is now hiring for several interesting positions--check out our
> >listings at www.firaxis.com
> >
> >Brian Reynolds
> >Alpha Centauri Designer
> >FIRAXIS Games
>
> So, why's Fireaxis spamming the NG dedicated to a Microprose game?....
> ;p
>
> --
> Darkhalf at Mindspring dot com
> -----------------------------------------------------
> | Meddle not in the affairs of dragons |
> | For you are crunchy and taste good with ketchup |
> -----------------------------------------------------
--
"You keep using that word. I do not think
it means what you think it means."
Inigo Montoya
Aol I.M. = JoelMunday
ICQ = 11829157
Brian Reynolds
DarkHalf
Reynolds) wrote:
So, why's Fireaxis spamming the NG dedicated to a Microprose game?....
Andrew R. Gillett
> Hi All,
>
> Ever thought of making these games for a living?
>
> FIRAXIS is now hiring for several interesting positions--check out our
> listings at www.firaxis.com
Don't suppose you have a UK division? ;)
--
Andrew Gillett http://argnet.fatal-design.com/ ICQ: See homepage
"Well, as you know Stew, I love my God, my Queen, AND my fellow countrymen.
And I can tell you, It's a bugger trying to juggle it so they don't find out
about each other." - Richard Herring
Stefan Blomskog
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Stefan Blomskog
s...@canit.se
"In an insane world, the insane is sane."
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Krud
Brian Reynolds wrote in message <37150241...@news.clark.net>...
>Hi All,
>
>Ever thought of making these games for a living?
>
>FIRAXIS is now hiring for several interesting positions--check out our
>listings at www.firaxis.com
And there's a great Pizza place right down the street from their offices
(Lido's). I would apply for a job if I wasn't so lazy.
-Krud
DarkHalf
Heh. I'd apply if I had the experience/education I assume they
require... ;p
Jon Nunn
brey...@firaxis.com (Brian Reynolds) wrote:
> Hi All,
>
> Ever thought of making these games for a living?
>
> FIRAXIS is now hiring for several interesting positions--check out our
> listings at www.firaxis.com
>
I didn't know that people were still using Assembly Langaue
with the built in graphic acceleration features of Pentium MMXs.
(I had thought the whole point the extra hardware support for
graphics MMX introduced was to allow programers to not have to
use assembly for fast-drawing.)
For the Web Master Programmer position, have you consirded using Java
Servlets as an alternative to cgi?
--
Jon Nunn
Programmer Analyst
Friends Don't Let Friends Do Cobol
http://members.home.net/jonnunn/
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Neale Davidson
> with the built in graphic acceleration features of Pentium MMXs.
> (I had thought the whole point the extra hardware support for
> graphics MMX introduced was to allow programers to not have to
> use assembly for fast-drawing.)
It would be rare, but it would also depend on which compiler that Firaxis
enjoys using. Truth be told, though, I suspect that this is more useful to
know that a programmer is skilled at optimizing his code.
The skills set did seem to be about two years past its day, though.
Of course, that may have been the last time the developers looked
away from their screens! ;>
Neale
Neil Fradkin
>Servlets as an alternative to cgi?
-shameless plug-
If you do I have some great Java Servlet tools that provide scalable,
distributed, Servlet handling for Netscape (on any platform) and IIS and
soon for Apache as well.
-end shameless plug-
denn...@telepath.com
"Neale Davidson" <ne...@iquest.net> wrote:
> > I didn't know that people were still using Assembly Langaue
> > with the built in graphic acceleration features of Pentium MMXs.
> > (I had thought the whole point the extra hardware support for
> > graphics MMX introduced was to allow programers to not have to
> > use assembly for fast-drawing.)
>
> It would be rare, but it would also depend on which compiler that Firaxis
> enjoys using. Truth be told, though, I suspect that this is more useful to
> know that a programmer is skilled at optimizing his code.
>
A good optimizing compiler makes that not only completly unnessecary, but
very often counterproductive. Compiler writers know *all* the tricks, and
they can write the compiler to consider way more things than a lone human
could hope to.
--
T.E.D.
Jeff George
Krud wrote in message ...
>>
>>Ever thought of making these games for a living?
>>
>>FIRAXIS is now hiring for several interesting positions--check out our
>>listings at www.firaxis.com
>
>
>(Lido's). I would apply for a job if I wasn't so lazy.
>
>
>
I'm glad I'm lazy. Otherwise I'd probably conquer the world.
JMG
Neale Davidson
>unnessecary, but very often counterproductive. Compiler writers
>know *all* the tricks, and they can write the compiler to consider way
>more things than a lone human could hope to.
Yes, and no. A skilled 'assembly level' programmer is more likely
to be adept at strong algorithms at the start. Not neccesarily true
anymore, since assembly isn't very highly sought after. I, for instance,
haven't done assembly in years, and very likely will never have to.
I did, however, learn a few new skills and habits from the language
from way back when. Though I admit I couldn't code assembly /now/
to save my life...
Neale
Gus Smedstad
>
> In article <U%2R2.161$F4....@news1.iquest.net>,
> "Neale Davidson" <ne...@iquest.net> wrote:
> > > I didn't know that people were still using Assembly Langaue
> > > with the built in graphic acceleration features of Pentium MMXs.
> > > (I had thought the whole point the extra hardware support for
> > > graphics MMX introduced was to allow programers to not have to
> > > use assembly for fast-drawing.)
> >
> > It would be rare, but it would also depend on which compiler that Firaxis
> > enjoys using. Truth be told, though, I suspect that this is more useful to
> > know that a programmer is skilled at optimizing his code.
> >
>
> very often counterproductive. Compiler writers know *all* the tricks, and
> they can write the compiler to consider way more things than a lone human
> could hope to.
That's not entirely true. Granted, I haven't felt a need to touch
assembler in years, and I grew up living and breathing the stuff.
Machine language, actually, since my first machine didn't have enough
ROM for an assembler.
However, optimization is still important at a level that compilers don't
understand. To take the most obvious example, choice of algorithm.
Going from ord(n^2) to ord(n log n) can be quite significant. And
sometimes by spending a little memory, you can eliminate the cost
entirely with a set of pointers.
Another point is that it's still highly useful to *read* assembler. On
occasion I need to step through disassembly when debugging, because
something funky is happening that isn't obvious at the source level.
- Gus
AI programmer and general handyman on Heroes III
New World Computing
p.s. Too bad Firaxis wasn't hiring 8 months ago... but I'm happy now,
and that's the point, isn't it?
p.p.s. Firaxis's coffee machine is much nicer than ours. But we have
better views.
Neil Fradkin
>> A good optimizing compiler makes that not only completely unnecessary,
but
>> very often counterproductive.
>That's not entirely true.
>
>However, optimization is still important at a level that compilers don't
>understand. To take the most obvious example, choice of algorithm.
>Going from ord(n^2) to ord(n log n) can be quite significant. And
>sometimes by spending a little memory, you can eliminate the cost
>entirely with a set of pointers.
I'm glad someone replied to this. Even the best optimizing compilers
know absolutely nothing about what your code is trying to accomplish.
Lacking context, there is only so much an optimizing compiler can do. For
time critical routines it's still very useful to read over the asm generated
by an optimizing compiler to see if further optimization based on knowledge
of the task and the rest of the system is possible.
>Another point is that it's still highly useful to *read* assembler. On
>occasion I need to step through disassembly when debugging, because
>something funky is happening that isn't obvious at the source level.
You know when you have to go down to the assembly in the debugger that
it's going to be a bad day. In my job now I work with CORBA based
distributed computing, I have days where I'm debugging down into the asm of
multiple processes on multiple machines at the same time, ugh! (you can tell
those days by the tone of my postings ;)
>p.s. Too bad Firaxis wasn't hiring 8 months ago... but I'm happy now,
>and that's the point, isn't it?
Too bad I'm much too happy doing 70% Java and 30% C++ in my job now to
go back to all C++ (even if it were for games). The stress level of 100%
C++, especially if even a little asm is thrown in, is much too high now that
I'm used to the easy life of a Java programmer ;) However if they ever feel
the need to contract out some Java Servlet work...
>p.p.s. Firaxis's coffee machine is much nicer than ours. But we have
>better views.
Coffee, that stuff will kill you. Where's the picture of the fridge full
of free juice and pop ;)
Jon Nunn
>
> However, optimization is still important at a level that compilers don't
> understand. To take the most obvious example, choice of algorithm.
> Going from ord(n^2) to ord(n log n) can be quite significant. And
> sometimes by spending a little memory, you can eliminate the cost
> entirely with a set of pointers.
>
code, so it doesn't qualify as optimization in my mind. Optimazations are more
like using intermediate String Buffers instead of Strings.
> Another point is that it's still highly useful to *read* assembler. On
> occasion I need to step through disassembly when debugging, because
> something funky is happening that isn't obvious at the source level.
>
Myself, I'd find the assembly langage version of the code much harder to make
heads or tails out of than the source code itself, I usually go with add
print statements to document what's happening, that are commented out before
releasing the code.
> - Gus
> AI programmer and general handyman on Heroes III
> New World Computing
>
> p.s. Too bad Firaxis wasn't hiring 8 months ago... but I'm happy now,
> and that's the point, isn't it?
> p.p.s. Firaxis's coffee machine is much nicer than ours. But we have
> better views.
>
--
Jon Nunn
Programmer Analyst
Friends Don't Let Friends Do Cobol
http://members.home.net/jonnunn/
-----------== Posted via Deja News, The Discussion Network ==----------
Ralph Trickey
>On Wed, 14 Apr 1999 11:07:52 GMT, "Krud" <au...@nospam.home.com> wrote:
>
>>
>>Brian Reynolds wrote in message <37150241...@news.clark.net>...
>>>Hi All,
>>>
>>>Ever thought of making these games for a living?
>>>
>>>FIRAXIS is now hiring for several interesting positions--check out our
>>>listings at www.firaxis.com
>>
>>
>>And there's a great Pizza place right down the street from their offices
>>(Lido's). I would apply for a job if I wasn't so lazy.
>
>Heh. I'd apply if I had the experience/education I assume they
>require... ;p
>
I don't know, one of the requirements was creative writing skills.<g>
--
Ralph Trickey <Ralph....@BigFoot.Com.RemoveToEmail>
Gus Smedstad
>
> >
> > However, optimization is still important at a level that compilers don't
> > understand. To take the most obvious example, choice of algorithm.
> > Going from ord(n^2) to ord(n log n) can be quite significant. And
> > sometimes by spending a little memory, you can eliminate the cost
> > entirely with a set of pointers.
> >
> Choice of algorithm should be the first step in designing a given module of
> code, so it doesn't qualify as optimization in my mind. Optimazations are more
> like using intermediate String Buffers instead of Strings.
>
Keep in mind the original context; what sort of skills is Firaxis
looking for? In that context, "knowing the right algorithms and how to
choose them" is a skill that directly affects the speed of the code.
My point is that writing fast code is still a skill, despite optimizing
compilers. And frequently it's at a level that can easily be called
optimization.
For example, testing a condition before entering a loop that avoids
entering the loop. I did one of those yesterday. There was no way the
compiler could know that if a given function returned false, the same
function with different parameters in the innermost loop would always
return false.
Heck, you don't always know the right answer when you start, anyway. If
you did, you could design the whole program before you coding a single
line, and you'd never have a bug, or need to rewrite something to
improve the speed. Right? Any followers of Dijkstra here in the real
world? I suspect not.
I would say that any time you re-write something for speed, even if it's
a very high level change like changing the algorithm, that is by
definition an optimization.
I've done those, too. My original approach was the correct one, but too
slow. I had to make compromises in order to make the game playable.
Which meant I had to painstakingly tweak the algorithm, deciding when to
discard "best choices" in favor of speed.
Shane
Greg Locock
Cheers
Greg Locock
Brian Reynolds wrote:
>
> Hi All,
>
> Ever thought of making these games for a living?
>
> FIRAXIS is now hiring for several interesting positions--check out our
> listings at www.firaxis.com
>
DarkHalf
wrote:
>In article <37150241...@news.clark.net>,
> brey...@firaxis.com (Brian Reynolds) wrote:
>> Hi All,
>>
>> Ever thought of making these games for a living?
>>
>> FIRAXIS is now hiring for several interesting positions--check out our
>> listings at www.firaxis.com
>>
>I checked out the listings, found some interesting things.
>
>I didn't know that people were still using Assembly Langaue
>with the built in graphic acceleration features of Pentium MMXs.
>(I had thought the whole point the extra hardware support for
>graphics MMX introduced was to allow programers to not have to
>use assembly for fast-drawing.)
Assembly language does, however, have the advantage of being more
compact. Part of the reason many programs now days are so massive is
the "shortcuts" out there to make programming easier.
Or so I've been informed by a couple programmers I've known...
DarkHalf
Ralph....@BigFoot.com.RemoveToEmail (Ralph Trickey) wrote:
>On Wed, 14 Apr 1999 12:45:05 GMT, not...@nomail.com (DarkHalf) wrote:
>
>>On Wed, 14 Apr 1999 11:07:52 GMT, "Krud" <au...@nospam.home.com> wrote:
>>
>>>
>>>Brian Reynolds wrote in message <37150241...@news.clark.net>...
>>>>Hi All,
>>>>
>>>>Ever thought of making these games for a living?
>>>>
>>>>FIRAXIS is now hiring for several interesting positions--check out our
>>>>listings at www.firaxis.com
>>>
>>>
>>>And there's a great Pizza place right down the street from their offices
>>>(Lido's). I would apply for a job if I wasn't so lazy.
>>
>>Heh. I'd apply if I had the experience/education I assume they
>>require... ;p
>>
>I don't know, one of the requirements was creative writing skills.<g>
Hmm, well, I do creative writing. I hope someday to get my skills up
to the point where I can write something publishable...
Jon Nunn
> >I didn't know that people were still using Assembly Langaue
> >with the built in graphic acceleration features of Pentium MMXs.
> >(I had thought the whole point the extra hardware support for
> >graphics MMX introduced was to allow programers to not have to
> >use assembly for fast-drawing.)
>
> Assembly language does, however, have the advantage of being more
> compact. Part of the reason many programs now days are so massive is
> the "shortcuts" out there to make programming easier.
>
You must be refering to the executable, as expressing ideas in
take more space in Assembly than in any high level
programming language, simular to being forced to communicate
via cave-man grunts.
Lots of Programs were huge before Object-Oriented langages well developed,
it fact it was the procedure code escaping programers grasp was the
big reason for Object-Oriented development.
The big reason programs are huge now is more to do with them encorping video
files and to a lessor extent audio files. (Plus we have faster processers,
more RAM, and larger Hardrives, and program size increases and program speed
decreases to counter the effects of new machines.)
Kornelis Sietsma
>In article <U%2R2.161$F4....@news1.iquest.net>,
> "Neale Davidson" <ne...@iquest.net> wrote:
>> > I didn't know that people were still using Assembly Langaue
>> > with the built in graphic acceleration features of Pentium MMXs.
>> > (I had thought the whole point the extra hardware support for
>> > graphics MMX introduced was to allow programers to not have to
>> > use assembly for fast-drawing.)
>>
>> It would be rare, but it would also depend on which compiler that Firaxis
>> enjoys using. Truth be told, though, I suspect that this is more useful to
>> know that a programmer is skilled at optimizing his code.
>>
>
>A good optimizing compiler makes that not only completly unnessecary, but
>very often counterproductive. Compiler writers know *all* the tricks, and
>they can write the compiler to consider way more things than a lone human
>could hope to.
Umm... exactly *which* compiler knows "all the tricks" about MMX? In my
experience, compilers always lag a long way behind the changes in CPUs.
And I doubt a games company can afford to wait that long!
Also, a good optimising compiler can make a big difference to 99% of the
code in a program, but you really need to code that last 1% in assembler if
you want to do fast graphics manipulation. There are just far too many
tweaks that an informed programmer can make, that a compiler just can't
cope with.
A simple example. Imagine you need to do some fast floating point maths.
You (as the programmer) know that the numbers you are handling are within a
limited range of values, and don't need to be extremely precise. You can
decide to use fixed-point integer maths for that section of code -
something the compiler could never do, as it couldn't make the same
assumptions that you can.
-Korny
--
Kornelis Sietsma http://zikzak.net/~korny icq: 2039172
e-mail: ko...@zikzak.net or ko...@eisa.net.au
Krud
Jeff George wrote in message <92411045...@news.remarQ.com>...
>
>Krud wrote in message ...
>>
>>
>>(Lido's). I would apply for a job if I wasn't so lazy.
>>
>>
>I'm glad I'm lazy. Otherwise I'd probably conquer the world.
Heh, heh, you know that's a very good point. Just think how much work
that would be....
-Krud
Stefan Blomskog
>
> On Wed, 14 Apr 1999 12:45:05 GMT, not...@nomail.com (DarkHalf) wrote:
>
> >On Wed, 14 Apr 1999 11:07:52 GMT, "Krud" <au...@nospam.home.com> wrote:
> >
> >>
> >>Brian Reynolds wrote in message <37150241...@news.clark.net>...
> >>>Hi All,
> >>>
> >>>Ever thought of making these games for a living?
> >>>
> >>>FIRAXIS is now hiring for several interesting positions--check out our
> >>>listings at www.firaxis.com
> >>
> >>
> >>(Lido's). I would apply for a job if I wasn't so lazy.
> >
> >require... ;p
> >
> I don't know, one of the requirements was creative writing skills.<g>
Yeah, if that was enough I would be applying now.... :-)
Jon Nunn
ko...@zikzak.net wrote:
> denn...@telepath.com wrote:
>
> Also, a good optimising compiler can make a big difference to 99% of the
> code in a program, but you really need to code that last 1% in assembler if
> you want to do fast graphics manipulation. There are just far too many
> tweaks that an informed programmer can make, that a compiler just can't
> cope with.
>
> A simple example. Imagine you need to do some fast floating point maths.
> You (as the programmer) know that the numbers you are handling are within a
> limited range of values, and don't need to be extremely precise. You can
> decide to use fixed-point integer maths for that section of code -
> something the compiler could never do, as it couldn't make the same
> assumptions that you can.
>
Yes, this is a clasic optimzation that compilars can't perform and even if it
could, in many cases would be undesirable. But there's no need to drop to
assembly level to do this.
If compilars still don't know about the realtively new massive memory move
instruction, (I think that was introduced MMX) that could be a reason
to drop to assembly level.
denn...@telepath.com
Gus Smedstad <g...@nwcomputing.com> wrote:
> For example, testing a condition before entering a loop that avoids
> entering the loop. I did one of those yesterday. There was no way the
> compiler could know that if a given function returned false, the same
> function with different parameters in the innermost loop would always
> return false.
Yes, but that's not something that would be helped by knowledge of Pentuim
assembly language, which is the topic of conversation here! It (should be)
quite true that you have way better high-level knowledge of what is going on
in your code than the compiler. But as for being able to look at the assembly
output and find a better way of doing things, meer mortals can't hope to
compete with a decent optimizing compiler.
--
T.E.D.
denn...@telepath.com
ko...@zikzak.net wrote:
> denn...@telepath.com wrote:
>
> A simple example. Imagine you need to do some fast floating point maths.
> You (as the programmer) know that the numbers you are handling are within a
> limited range of values, and don't need to be extremely precise. You can
> decide to use fixed-point integer maths for that section of code -
> something the compiler could never do, as it couldn't make the same
> assumptions that you can.
But you don't need Assembly knowldege to do that! No amount of
looking over the assembly output is going to tell you that you can
use fixed-point instead. And fixed-point math can be written in any high-level
language (Ada even directly supports it).
(And actually fixed-point math can be *more* precise than floating-point,
depending on how far away from 10^0 you place the point)
Again, I'm not trying to claim that compilers are smart enough to notice that
you wrote an exhaustive-permutation sort and replace it with a radix sort.
What I'm trying to say is that *at the machine level* you generally aren't
going to be able to beat the compiler's optimizations by eyballing the output
yourself and then mucking with the high-level source code to try to get
different results.
Gerry Quinn
>In article <3715464C...@nwcomputing.com>,
> Gus Smedstad <g...@nwcomputing.com> wrote:
>
>> For example, testing a condition before entering a loop that avoids
>> entering the loop. I did one of those yesterday. There was no way the
>> compiler could know that if a given function returned false, the same
>> function with different parameters in the innermost loop would always
>> return false.
>
>Yes, but that's not something that would be helped by knowledge of Pentuim
>assembly language, which is the topic of conversation here! It (should be)
>quite true that you have way better high-level knowledge of what is going on
>in your code than the compiler. But as for being able to look at the assembly
>output and find a better way of doing things, meer mortals can't hope to
>compete with a decent optimizing compiler.
>
But game development software gods can!
- Gerry Quinn
http://bindweed.com
iain...@enterprise.net
What? - and go through all the aggro you get in the newsgroups....??!
Yooors,
Iain.
On Wed, 14 Apr 1999 02:51:06 GMT, brey...@firaxis.com (Brian
Reynolds) wrote:
> Hi All,
>
> Ever thought of making these games for a living?
>
> FIRAXIS is now hiring for several interesting positions--check out our
> listings at www.firaxis.com
>
> Brian Reynolds
> Alpha Centauri Designer
> FIRAXIS Games
You are cordially invited to enter "the Scottish", one of the world's
oldest and most prestigious competitive photographic exhibitions -
http://www.micromedia.net/spf/salonhom.htm
Sent from within Agent. To reply, remove the Q
David Bohnenberger
obsessive strat gamers.
ddnguyen
Brian Reynolds wrote in message <37150241...@news.clark.net>...
>Hi All,
>
>Ever thought of making these games for a living?
>
>FIRAXIS is now hiring for several interesting positions--check out our
>listings at www.firaxis.com
>
>Brian Reynolds
>Alpha Centauri Designer
>FIRAXIS Games
>
Does that hiring icon scare anyone else? It kinda looks evil. Best of luck
8^).
-ddn
Riboflavin
>So, why's Fireaxis spamming the NG dedicated to a Microprose game?....
>;p
Brian Reynolds happens to be the guy who designed MPS's Civ2, and Sid Meier
of the same company did civ1. Any questions?
--
Kevin Allegood ribotr...@mindspring.pants.com
Remove the pants from my email address to reply
"At least one could get something through Trotsky's skull."
- Joseph Michael Bay
Jason Willoughby
Which just means they should quit wasting their time hand-optimizing code
and write the general case into a compiler. The Pentium Compiler Group at
<http://www.goof.com/pcg/> would be a good place to start, for instance.
There's no more reason to keep rewriting graphics handling routines than
there is to rewrite disk drivers or any of the rest of that stuff.
Ralph Trickey
>In article <3715464C...@nwcomputing.com>,
> Gus Smedstad <g...@nwcomputing.com> wrote:
>
>> For example, testing a condition before entering a loop that avoids
>> entering the loop. I did one of those yesterday. There was no way the
>> compiler could know that if a given function returned false, the same
>> function with different parameters in the innermost loop would always
>> return false.
>
>Yes, but that's not something that would be helped by knowledge of Pentuim
>assembly language, which is the topic of conversation here! It (should be)
>quite true that you have way better high-level knowledge of what is going on
>in your code than the compiler. But as for being able to look at the assembly
>output and find a better way of doing things, meer mortals can't hope to
>compete with a decent optimizing compiler.
>
Nonsense. Humans can do a better job because they have a high level
knowledge of the inputs and expected behaviour. At the micro level of
re-arranging instructions in a block to optimize the pipeline, I agree
that a good optimizing compiler would be better, most of the time. But
the major gains are made at a higher level, by loop unrolling,
re-arranging the jumps and loops in the code to ensure that the
pipeline stays full, forcing a variable to stay in a register, and
other optimizations that the compiler can't know about because it
doesn't know the critical path (neither do humans most of the time,
but that's another topic<g>).
Writing a 'perfect' optimizing compiler is just as difficult as
writing a 'perfect' AI. It should be able to beat you tactically, but
will lose strategically.
Ralph
--
Ralph Trickey <Ralph....@BigFoot.Com.RemoveToEmail>
Clement McGann
wrote:
[snip]
>
>Keep in mind the original context; what sort of skills is Firaxis
>looking for? In that context, "knowing the right algorithms and how to
>choose them" is a skill that directly affects the speed of the code.
>
>My point is that writing fast code is still a skill, despite optimizing
>compilers. And frequently it's at a level that can easily be called
>optimization.
>
It depends on how good the programmer is. The good guys are rare.
C++ imho does not have a good multi-pass optimising compiler
There are some very good libraries - but that is another matter
OO by it's nature can hide inefficiencies.
>
I have seen too many examples of hand optimisation which have
resulted in bugs, or they make the code too difficult to maintain
you have to re-write it - and that's expensive
>
There are three rules of optimisation
1 - don't do it; 2 - don't do it yet;
3 - if you must do it, do it this way ... ...
>
My preference would be a good optimising compiler
but that would rule out C++, so back to square one.
>
>For example, testing a condition before entering a loop that avoids
>entering the loop. I did one of those yesterday. There was no way the
>compiler could know that if a given function returned false, the same
>function with different parameters in the innermost loop would always
>return false.
Perhaps I'm missing something here - if so - why the parameters?
>
>Heck, you don't always know the right answer when you start, anyway. If
>you did, you could design the whole program before you coding a single
>line, and you'd never have a bug, or need to rewrite something to
>improve the speed. Right? Any followers of Dijkstra here in the real
>world? I suspect not.
Edsger W Dijkstra said
"Programming is the judicious postponement of decisions and commitments"
Clement McGann
>In article <7f53i6$nrd$1...@nnrp1.dejanews.com>, denn...@telepath.com wrote:
>>In article <3715464C...@nwcomputing.com>,
>> Gus Smedstad <g...@nwcomputing.com> wrote:
>>
[snip]
>>Yes, but that's not something that would be helped by knowledge of Pentuim
>>assembly language, which is the topic of conversation here! It (should be)
>>quite true that you have way better high-level knowledge of what is going on
>>in your code than the compiler. But as for being able to look at the assembly
>>output and find a better way of doing things, meer mortals can't hope to
>>compete with a decent optimizing compiler.
>>
>
>But game development software gods can!
>
which is why their games are full of bugs ;)
Clement McGann
>On Wed, 14 Apr 1999 14:37:28 GMT, Jon Nunn <jn...@my-dejanews.com>
>wrote:
>
>>In article <37150241...@news.clark.net>,
>> brey...@firaxis.com (Brian Reynolds) wrote:
>>> Hi All,
>>>
>>> Ever thought of making these games for a living?
>>>
>>> FIRAXIS is now hiring for several interesting positions--check out our
>>> listings at www.firaxis.com
>>>
>>I checked out the listings, found some interesting things.
>>
>>I didn't know that people were still using Assembly Langaue
>>with the built in graphic acceleration features of Pentium MMXs.
>>(I had thought the whole point the extra hardware support for
>>graphics MMX introduced was to allow programers to not have to
>>use assembly for fast-drawing.)
>
>Assembly language does, however, have the advantage of being more
>compact. Part of the reason many programs now days are so massive is
>the "shortcuts" out there to make programming easier.
>
>Or so I've been informed by a couple programmers I've known...
>
>--
>Darkhalf at Mindspring dot com
>-----------------------------------------------------
>| Meddle not in the affairs of dragons |
>| For you are crunchy and taste good with ketchup |
>-----------------------------------------------------
How to make an executable bigger:
start with a good game like smac from fraxis
give it to ea and ask them to produce an
english version for europe
Gus Smedstad
> >For example, testing a condition before entering a loop that avoids
> >entering the loop. I did one of those yesterday. There was no way the
> >compiler could know that if a given function returned false, the same
> >function with different parameters in the innermost loop would always
> >return false.
> Perhaps I'm missing something here - if so - why the parameters?
The specific case I was thinking of was a random object placement
function.
I'm checking all the places I can put a candidate object. I know for a
fact that the object will always touch a given square, because that's
one of the requirements. If it is not legal for the candidate object to
touch that square, there's no point in checking the list of possible
positions for that object.
Make any more sense?
> >Heck, you don't always know the right answer when you start, anyway. If
> >you did, you could design the whole program before you coding a single
> >line, and you'd never have a bug, or need to rewrite something to
> >improve the speed. Right? Any followers of Dijkstra here in the real
> >world? I suspect not.
> Edsger W Dijkstra said
> "Programming is the judicious postponement of decisions and commitments"
That's interesting - but my point was that Dijkstra was very rigid about
proofs, as they apply to programming. He really did believe it was
reasonable to determine, by proof, everything about a program before
writing it.
That's great for simple examples, but silly for real projects.
Anyway, we've wandered REALLY far afield of the original topic. Or
anything that most of the readers of c.s.i.p.g.s. or a.g.f.a-c or
a.g.civ2 would care about.
Jason Willoughby
> In article <1bs5f7...@platinum.gate.net>, Jason Willoughby <jwil...@gate.net> wrote:
>>Which just means they should quit wasting their time hand-optimizing code
>>and write the general case into a compiler. The Pentium Compiler Group at
>><http://www.goof.com/pcg/> would be a good place to start, for instance.
> Maybe they would prefer to earn money!
Computer time is so much cheaper than human time, that creating,
improving, or even just learning to use any (useful) tool will necessarily
save money in the long run. Whether the cost is worth it in the short
term, well, that usually depends on where the deadline is...
Gerry Quinn
>Gerry Quinn <ger...@indigo.ie> wrote:
>>>meer mortals can't hope to compete with a decent optimizing compiler.
>
>> But game development software gods can!
>
>and write the general case into a compiler. The Pentium Compiler Group at
><http://www.goof.com/pcg/> would be a good place to start, for instance.
>there is to rewrite disk drivers or any of the rest of that stuff.
Maybe they would prefer to earn money!
Seriously, people (especially academics) have been saying for years that
people can't compete with compilers. For most people, including me, that is
probably the case. Nevertheless, I am sure that the top ASM coders will
thoroughly defeat compilers for the foreseeable future. Compilers are written
by humans, after all, who have to face the difficulty of implementing general
solutions rather than optimising specific problems. And any emulation tool a
compiler uses to test many solutions could also be used by a coder.
Gerry Quinn
>Gerry Quinn <ger...@indigo.ie> wrote:
>> In article <1bs5f7...@platinum.gate.net>, Jason Willoughby
> <jwil...@gate.net> wrote:
>>>Which just means they should quit wasting their time hand-optimizing code
>>>and write the general case into a compiler. The Pentium Compiler Group at
>>><http://www.goof.com/pcg/> would be a good place to start, for instance.
>
>
>improving, or even just learning to use any (useful) tool will necessarily
>save money in the long run. Whether the cost is worth it in the short
>term, well, that usually depends on where the deadline is...
Computer time is shorter than human time. The Pentium II lasted about nine
months, if that. Some coders may have optimised for it, compilers sure as
hell didn't...
Jon Nunn
> >
> >Computer time is so much cheaper than human time, that creating,
> >improving, or even just learning to use any (useful) tool will necessarily
> >save money in the long run. Whether the cost is worth it in the short
> >term, well, that usually depends on where the deadline is...
>
> Computer time is shorter than human time. The Pentium II lasted about nine
> months, if that. Some coders may have optimised for it, compilers sure as
> hell didn't...
>
The vast majority of computers are still Pentium II and below.
I think the median primary computer (first owner) is either one
of the last Pentium MMX or one of the first Pentium IIs.
The 486 is still fine for running programs written when 486 was
what the typical person has. It's only running programs written
after the Pentium came out that makes the 486 show its age.
--
Jon Nunn
Programmer Analyst
Friends Don't Let Friends Do Cobol
http://members.home.net/jonnunn/
-----------== Posted via Deja News, The Discussion Network ==----------
The Chris
>
> my cat's breath smells like catfood. . .
Hey just as I was reading this interesting observation my Alsatian
breathed over me - at least cats don't like the taste of their own
deposits, ahem.
The Chris
Christopher Tew
>p.s. Too bad Firaxis wasn't hiring 8 months ago... but I'm happy now,
>and that's the point, isn't it?
>p.p.s. Firaxis's coffee machine is much nicer than ours. But we have
>better views.
Yeah, but the part that will really sell any prospective Firaxis
employee is the free cookies from Sid's ma. Cool-ass coffee machines
are a dime a dozen, and having a great view is as easy as changing the
desktop background, but fresh baked cookies from Sid's ma are among
the most rare prizes of all!
Hmm. Giving people window offices on the tenth floor is a possible
work hazard during crunch. I wonder how many times they've had to
pull Brian off of the ledge because they had to ditch one of his pet
features to meet a deadline?
--
-------------------------------------------------|
We've just occupied the language | Another post by the
areas of your cerebral cortex; | unoffical RUDY POO
you will now generate auto-critique | CANDY ASS of Usenet,
-----VISIT MY FUN: http://www.lvdi.net/~tikicat--| Christopher Tew!
Ron Watkins
> assembly language, which is the topic of conversation here! It (should be)
> quite true that you have way better high-level knowledge of what is going on
> in your code than the compiler. But as for being able to look at the assembly
> compete with a decent optimizing compiler.
You're out of your mind. No computer can (yet) produce code that runs faster
than what a talented human can do, with specific knowledge of the algorithm
and the architecture of the chip.
Genetic algorithms may eventually produce other algorithms than are faster
than what humans can write. For instance, there's a genetic chip-designing
algorithm that has succeeded at least once in creating a circuit 10 times as
efficient as what skilled humans can make, and which takes advantage of
physical properties of chips that we do not yet understand. Apparently (I'm
not a chip designer myself, so can't vouch for this) it looks like God
designed it.
But for the moment, we're stuck with the old ways of having code write other
code, and no general purpose solution will ever beat the specialized case. If
you want to spend the time with it, you absolutely can write code that's
faster than what your compiler generates. However, you probably won't care
enough to bother. :-)
<<RON>>
Kornelis Sietsma
>In article <3718391b...@news.eisa.net.au>,
> ko...@zikzak.net wrote:
>> denn...@telepath.com wrote:
>>
>> A simple example. Imagine you need to do some fast floating point maths.
>> You (as the programmer) know that the numbers you are handling are within a
>> limited range of values, and don't need to be extremely precise. You can
>> decide to use fixed-point integer maths for that section of code -
>> something the compiler could never do, as it couldn't make the same
>> assumptions that you can.
>
>But you don't need Assembly knowldege to do that! No amount of
>looking over the assembly output is going to tell you that you can
>use fixed-point instead. And fixed-point math can be written in any high-level
>language (Ada even directly supports it).
Well, you *can* write it in C++ (which I'm assuming is the language used in
games development) - in fact I've used such methods in non-speed-dependant
code. But for tightly optimised code, you can do better in assembly -
mainly by making assumptions about the numbers that a compiler can't make.
For example, deciding whether the fixed point numbers can fit in specific
registers, making sure they don't overflow or underflow, etc.
Mind you, the best way to write such assembly is to first write the code in
C++, then re-write just the core speed-critical routines in assembly. I'm
not advocating writing huge scads of code in assembly - that way lies
madness!
But really, for games, the deciding factor would be raw data manipulation,
especially using such CPU tweaks as MMX code. I'll give you a real-world
example (from some old code of mine). I wanted to rapidly fill rectangular
blocks of pixels in an 8-bit bitmap with a fixed colour. I wrote the code
to do this in C++, and then converted it to inline assembly. Not even
ruthlessly optimal assembly - it only uses bog-standard 386 opcodes.
The full programs are at the end of this message - read them if you want.
The most important lines of each version are :
C++ version :
for (int row = 0; row < rhig; row++)
{
for (int col = 0; col < rwid; col++)
*pix++ = clr;
pix += linegap;
}
My handwritten asm inner loop :
rowloop:
push ecx
mov ecx, ebx
rep stosb
pop ecx
add edi, edx
loop rowloop
Borland C++ 'optimised' code (speed optimised for Pentium CPUs) :
@99:
xor edi,edi
mov edx,dword ptr [ebp+28]
cmp edi,edx
jge short @101
@100:
xor edx,edx
cmp esi,edx
jle short @104
@103:
mov byte ptr [eax],cl
inc eax
@105:
inc edx
cmp esi,edx
jg short @103
@104:
add eax,dword ptr [ebp-4]
@107:
inc edi
mov edx,dword ptr [ebp+28]
cmp edi,edx
jl short @100
Unfortunately I don't have a working version of GCC here - it has rather
better optimisations, and should do a better job. If anyone out there has
GCC running, could they try this code in it and post the results? The
Borland optimisations are very poor - they didn't even use a 'rep stosb'
instruction!
Note, my assembly would be a *lot* faster if I split the data into dwords
and used rep stosd. And even faster again if I used any CPU-specific
instructions. But I wanted to keep things simple :)
-Korny
Original code :
-------------------------------------------------------
void fastdrawrect(unsigned char *bmp, int pitch, int x1, int y1, int rwid,
int rhig, unsigned char clr)
{
unsigned char *pix = bmp + pitch * y1 + x1; // top left pixel
int linegap = pitch - rwid;
for (int row = 0; row < rhig; row++)
{
for (int col = 0; col < rwid; col++)
*pix++ = clr;
pix += linegap;
}
}
My assembly version :
-------------------------------------------------------
void fastdrawrect(unsigned char *bmp, int pitch, int x1, int y1, int rwid,
int rhig, unsigned char clr)
{
asm {
push edi
push eax
push ebx
push ecx
push edx
mov edi, bmp
// find top left corner
mov eax, y1
mov ebx, pitch
imul ebx
mov ebx, x1
add eax, ebx
add eax, edi
mov edi, eax
// find gap between lines
mov eax, pitch
mov ebx, rwid
sub eax, ebx
mov edx, eax // store gap size in edx
mov al, clr
mov ecx, rhig // loop counter
rowloop:
push ecx
mov ecx, ebx
rep stosb
pop ecx
add edi, edx
loop rowloop
pop edx
pop ecx
pop ebx
pop eax
pop edi
}
}
Borland C++ version
-------------------------------------------------------
fastdrawrect proc near
@98:
push ebp
mov ebp,esp
push ecx
push ebx
push esi
push edi
mov edx,dword ptr [ebp+12]
; ESI = rwid, ECX = clr, EDX = pitch
mov ebx,dword ptr [ebp+8]
mov eax,edx
mov esi,dword ptr [ebp+24]
; ESI = rwid, ECX = clr, EDX = pitch
imul eax,dword ptr [ebp+20]
add eax,ebx
mov ebx,dword ptr [ebp+16]
add eax,ebx
; EAX = pix, ESI = rwid, ECX = clr, EDX = pitch
sub edx,esi
mov ecx,dword ptr [ebp+32]
; EAX = pix, ESI = rwid, ECX = clr, EDX = pitch
mov dword ptr [ebp-4],edx
; EAX = pix, ESI = rwid, ECX = clr
@99:
xor edi,edi
mov edx,dword ptr [ebp+28]
cmp edi,edx
jge short @101
; EAX = pix, ESI = rwid, ECX = clr, EDI = row
@100:
xor edx,edx
cmp esi,edx
jle short @104
; EAX = pix, EDX = col, ESI = rwid, ECX = clr, EDI = row
@103:
mov byte ptr [eax],cl
inc eax
@105:
inc edx
cmp esi,edx
jg short @103
; EAX = pix, ESI = rwid, ECX = clr, EDI = row
@104:
add eax,dword ptr [ebp-4]
@107:
inc edi
mov edx,dword ptr [ebp+28]
cmp edi,edx
jl short @100
;
@101:
pop edi
pop esi
pop ebx
pop ecx
pop ebp
ret
Ralph Trickey
(Christopher Tew) wrote:
>I stole this intro from Gus Smedstad.
>
>>p.s. Too bad Firaxis wasn't hiring 8 months ago... but I'm happy now,
>>and that's the point, isn't it?
>>p.p.s. Firaxis's coffee machine is much nicer than ours. But we have
>>better views.
>
>Yeah, but the part that will really sell any prospective Firaxis
>employee is the free cookies from Sid's ma. Cool-ass coffee machines
>are a dime a dozen, and having a great view is as easy as changing the
>desktop background, but fresh baked cookies from Sid's ma are among
>the most rare prizes of all!
>
>Hmm. Giving people window offices on the tenth floor is a possible
>work hazard during crunch. I wonder how many times they've had to
>pull Brian off of the ledge because they had to ditch one of his pet
>features to meet a deadline?
>
I don't know, in a couple of jobs I've worked at, I would have loved
it if they had given some employees window offices. It might have kept
some of the rampant egos in check.
I've got a view of Pike's Peak from my window. It's on the first
floor, though<g>.
Gus Smedstad
>
> >Hmm. Giving people window offices on the tenth floor is a possible
> >work hazard during crunch. I wonder how many times they've had to
> >pull Brian off of the ledge because they had to ditch one of his pet
> >features to meet a deadline?
> >
> I don't know, in a couple of jobs I've worked at, I would have loved
> it if they had given some employees window offices. It might have kept
> some of the rampant egos in check.
>
Huh. Our windows don't open. I never wondered why, before.
- Gus
George Ruof
>Huh. Our windows don't open. I never wondered why, before.
Yeah, you gotta watch of for that fall from the second story onto the
grass. Might sprain a typing finger or something. :)
They took my window away completely a couple of weeks before we shipped
Heroes 3. Maybe they were trying to tell me something.
--
George Ruof
gr...@pacificnet.net
Senior Programmer
New World Computing
Daran
>Mind you, the best way to write such assembly is to first write the code in
>C++, then re-write just the core speed-critical routines in assembly.
Of course
>I'm
>not advocating writing huge scads of code in assembly - that way lies
>madness!
This is why some of us older programmers are mad!
Daran
Jon Nunn
<3B6CFC0E44938A26.F8FE7AD3...@library-proxy.airnews.net
>, gr...@pacificnet.net (George Ruof) wrote:
> Gus Smedstad <g...@nwcomputing.com> wrote:
>
> >Huh. Our windows don't open. I never wondered why, before.
>
> Yeah, you gotta watch of for that fall from the second story onto the
> grass. Might sprain a typing finger or something. :)
>
Or the fall from the first story onto executives. (One of the Dilbert
episodes.)