Send it to the optimizer!

[the Dutchman]

Isn't there a profession like that,programmers that optimize software regardless of what it's used for???

If not i'm off to school!;)

[David Hayward]

Isn't there a profession like that,programmers that optimize software regardless of what it's used for???

If not i'm off to school!;)

No. Optimizing something as complicated as this game would require the programmer to have detailed knowledge of every algorithm. Dumping this on a new programmer would be a disaster. It would probably take them weeks, if not months, to get familiar enough with it before being allowed to make significant changes.

[Zappatime]

...... well how about The Central Scrutinizer then? ;)

[David Hayward]

...... well how about The Central Scrutinizer then? ;)

They are called "users".

[the Dutchman]

It seems to me it's just a matter of to many vertices at the right place at the wrong time.......:-P

[the Dutchman]

They are called "users".


I challenge you to a disk duel!

[Oldschool61]

No. Optimizing something as complicated as this game would require the programmer to have detailed knowledge of every algorithm. Dumping this on a new programmer would be a disaster. It would probably take them weeks, if not months, to get familiar enough with it before being allowed to make significant changes.

Unless this programmer already has flight sim exp. then it might help. Maybe the RoF programmers looking for a part time job

[David Hayward]

Unless this programmer already has flight sim exp. then it might help. Maybe the RoF programmers looking for a part time job

Flight sim programming experience probably only helps if the sims have similar engines. I'm pretty sure that CoD is unique.

In fact, flight sim experience might do more harm than good if the programmer makes wrong assumptions based on previous experience.

[Blue Scorpion]

Programmers are responsible for optimising their own code as far as is possible and practicable based on the companies rules of coding practice, and design documents.

You then produce debug builds with built in profiling code, this tracks resource allocation, number of calls to those areas requiring the greatest processing power, data that can never be accessed due to logic errors and so on, giving hints to any potential bottlenecks. Any potential problems are then passed back to the team who were responsible for that area of code, and they in turn look at ways of improving it.

This is an iterative process, and code may go back and forth many times on complex projects while the code is optimised and bug fixed and additional features added or expanded.

Unfortunately, as is usually the case, bug fixes, and new functions change code behaviour in ways that can never have been foreseen. Due partly to the way a compiler organises data allocation and optimizes code internally during compilation; but more likely, to the left hand not fully understanding how the right hand went about achieving a particular solution. This in turn, often forces another look at code to remove these bottlenecks, sometimes requiring an investigation of the problem at machine code level.

Eventually, you reach a point where performance is acceptable or within design limits, at which point the process generally stops; until new additions or updates change the code again requiring a fresh look at the problem.

Flight sim programming experience probably only helps if the sims have similar engines. I'm pretty sure that CoD is unique.

In fact, flight sim experience might do more harm than good if the programmer makes wrong assumptions based on previous experience.

Coding, is coding, is coding, all programmers working for well organised software houses produce their code in line with design documents laid out during an earlier phase of development, if any such problems are going to occur it is during the design phase not during coding . Good coding practice also demands that programmers comment their code anywhere there may be ambiguity or complex algorithms so that new or reallocated staff can quickly establish an understanding of the code at hand.

[Oldschool61]

Programmers are responsible for optimising their own code as far as is possible and practicable based on the companies rules of coding practice, and design documents.

You then produce debug builds with built in profiling code, this tracks resource allocation, number of calls to those areas requiring the greatest processing power, data that can never be accessed due to logic errors and so on, giving hints to any potential bottlenecks. Any potential problems are then passed back to the team who were responsible for that area of code, and they in turn look at ways of improving it.

This is an iterative process, and code may go back and forth many times on complex projects while the code is optimised and bug fixed and additional features added or expanded.

Unfortunately, as is usually the case, bug fixes, and new functions change code behaviour in ways that can never have been foreseen. Due partly to the way a compiler organises data allocation and optimizes code internally during compilation; but more likely, to the left hand not fully understanding how the right hand went about achieving a particular solution. This in turn, often forces another look at code to remove these bottlenecks, sometimes requiring an investigation of the problem at machine code level.

Eventually, you reach a point where performance is acceptable or within design limits, at which point the process generally stops; until new additions or updates change the code again requiring a fresh look at the problem.



Coding, is coding, is coding, all programmers working for well organised software houses produce their code in line with design documents laid out during an earlier phase of development, if any such problems are going to occur it is during the design phase not during coding . Good coding practice also demands that programmers comment their code anywhere there may be ambiguity or complex algorithms so that new or reallocated staff can quickly establish an understanding of the code at hand.

Sounds like someone know a little about programming...

[David Hayward]

Coding, is coding, is coding, all programmers working for well organised software houses produce their code in line with design documents laid out during an earlier phase of development, if any such problems are going to occur it is during the design phase not during coding . Good coding practice also demands that programmers comment their code anywhere there may be ambiguity or complex algorithms so that new or reallocated staff can quickly establish an understanding of the code at hand.

Coding is coding, but not all applications are so easy for a programmer to jump into without experience specific to that app. No amount of comments can make up for experience, especially for really complicated code (which I assume CoD is). Keep in mind that the person who coded the bug is usually the same person who entered the comments.