Skip to main content
added 116 characters in body
Source Link
RETRAC
  • 14.1k
  • 3
  • 44
  • 67

I cannot answer the question from a game design standpoint, and I suspect the real answer lies there. Hopefully someone will be able to preempt my answer here with that perspective.

Or does it actually require some kind of "expensive" mathematical calculation which earlier (arcade) hardware simply didn't live up to?

Such calculations are not particularly difficult. They would not use up very many processor cycles. Various ways to apply a curve to the acceleration rate would have been obvious to programmers at the time, if they wanted to implement such a feature.

The main limitation would be ROM space used for the routines. ROM was at an extreme premium on the earliest arcade platforms and consoles. Some of the earliest microprocessor-based arcade games had as little as 1 KB of ROM. The total number of instructions you can fit in that much space is measured in the hundreds.

Even by 1982, most games for the Atari 2600 are 4 or 8 KB and big arcade games were weighing in around 32 KB. Released in 1985, the Super Mario Bros. cartridge had 40 KB total of ROM. The designers would have been far less constrained, compared to even just a couple years before, when it comes to things like a couple dozen instructions to implement the feature you mention. This was not specific for the NES, and came from the general cost of ROM coming down; it would have benefited most platforms.

I cannot answer the question from a game design standpoint, and I suspect the real answer lies there. Hopefully someone will be able to preempt my answer here with that perspective.

Or does it actually require some kind of "expensive" mathematical calculation which earlier (arcade) hardware simply didn't live up to?

Such calculations are not particularly difficult. They would not use up very many processor cycles. Various ways to apply a curve to the acceleration rate would have been obvious to programmers at the time, if they wanted to implement such a feature.

The main limitation would be ROM space used for the routines. ROM was at an extreme premium on the earliest arcade platforms and consoles. Some of the earliest microprocessor-based arcade games had as little as 1 KB of ROM. The total number of instructions you can fit in that much space is measured in the hundreds.

Even by 1982, most games for the Atari 2600 are 4 or 8 KB and big arcade games were weighing in around 32 KB. Released in 1985, the Super Mario Bros. cartridge had 40 KB total of ROM. The designers would have been far less constrained, compared to even just a couple years before, when it comes to things like a couple dozen instructions to implement the feature you mention.

I cannot answer the question from a game design standpoint, and I suspect the real answer lies there. Hopefully someone will be able to preempt my answer here with that perspective.

Or does it actually require some kind of "expensive" mathematical calculation which earlier (arcade) hardware simply didn't live up to?

Such calculations are not particularly difficult. They would not use up very many processor cycles. Various ways to apply a curve to the acceleration rate would have been obvious to programmers at the time, if they wanted to implement such a feature.

The main limitation would be ROM space used for the routines. ROM was at an extreme premium on the earliest arcade platforms and consoles. Some of the earliest microprocessor-based arcade games had as little as 1 KB of ROM. The total number of instructions you can fit in that much space is measured in the hundreds.

Even by 1982, most games for the Atari 2600 are 4 or 8 KB and big arcade games were weighing in around 32 KB. Released in 1985, the Super Mario Bros. cartridge had 40 KB total of ROM. The designers would have been far less constrained, compared to even just a couple years before, when it comes to things like a couple dozen instructions to implement the feature you mention. This was not specific for the NES, and came from the general cost of ROM coming down; it would have benefited most platforms.

Source Link
RETRAC
  • 14.1k
  • 3
  • 44
  • 67

I cannot answer the question from a game design standpoint, and I suspect the real answer lies there. Hopefully someone will be able to preempt my answer here with that perspective.

Or does it actually require some kind of "expensive" mathematical calculation which earlier (arcade) hardware simply didn't live up to?

Such calculations are not particularly difficult. They would not use up very many processor cycles. Various ways to apply a curve to the acceleration rate would have been obvious to programmers at the time, if they wanted to implement such a feature.

The main limitation would be ROM space used for the routines. ROM was at an extreme premium on the earliest arcade platforms and consoles. Some of the earliest microprocessor-based arcade games had as little as 1 KB of ROM. The total number of instructions you can fit in that much space is measured in the hundreds.

Even by 1982, most games for the Atari 2600 are 4 or 8 KB and big arcade games were weighing in around 32 KB. Released in 1985, the Super Mario Bros. cartridge had 40 KB total of ROM. The designers would have been far less constrained, compared to even just a couple years before, when it comes to things like a couple dozen instructions to implement the feature you mention.