Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

larstofus.com

Post reply on HN
Print view View original

21–30 of 186 posts

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#21

Post by scns »

lukan wrote: post #19
applfanboysbgon wrote: post #7

> Imagine a programmer asking a game designer if they could change their formula to use an 8 instead of a 9.5 because it is a number that the CPU prefers to calculate with. There is a very good argument to be made that a game designer should never have to worry about the runtime performance characteristics of binary arithmetic in their life, that’s a fate reserved for programmers Numeric characteristics are absolutel…

"and in many cases it is one of many silent contributing factors to a noticeable decrease in the quality of their game" Game designers are not so constrained anymore by the limits of the hardware, unless they want to push boundaries. Quality of a game is not just the most efficient runtime performance - it is mainly a question if the game is fun to play. Do the mechanics work. Are there severe bugs. Is the story cons…

> it is mainly a question if the game is fun to play.

10000x this. Miyamoto starts with a rudimentary prototype and asks himself this. Sadly it seems for many fun is an afterthought they try to patch in somehow.

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#22

Post by [deleted] »

lukan wrote: post #19
applfanboysbgon wrote: post #7

> Imagine a programmer asking a game designer if they could change their formula to use an 8 instead of a 9.5 because it is a number that the CPU prefers to calculate with. There is a very good argument to be made that a game designer should never have to worry about the runtime performance characteristics of binary arithmetic in their life, that’s a fate reserved for programmers Numeric characteristics are absolutel…

"and in many cases it is one of many silent contributing factors to a noticeable decrease in the quality of their game" Game designers are not so constrained anymore by the limits of the hardware, unless they want to push boundaries. Quality of a game is not just the most efficient runtime performance - it is mainly a question if the game is fun to play. Do the mechanics work. Are there severe bugs. Is the story cons…

[deleted]

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#23

Post by rawling »

cjbgkagh wrote: post #10
fweimer wrote: post #4

What language is this article talking where compilers don't optimize multiplication and division by powers of two? Even for division of signed integers, current compilers emit inline code that handles positive and negative values separately, still avoiding the division instruction (unless when optimizing for size, of course).

It was written in assembly so goes through an assembler instead of a compiler.

I assume GP is talking about the bit in the article that goes

> RCT does this trick all the time, and even in its OpenRCT2 version, this syntax hasn’t been changed, since compilers won’t do this optimization for you.

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#24

Post by sublinear »

lukan wrote: post #19
applfanboysbgon wrote: post #7

> Imagine a programmer asking a game designer if they could change their formula to use an 8 instead of a 9.5 because it is a number that the CPU prefers to calculate with. There is a very good argument to be made that a game designer should never have to worry about the runtime performance characteristics of binary arithmetic in their life, that’s a fate reserved for programmers Numeric characteristics are absolutel…

"and in many cases it is one of many silent contributing factors to a noticeable decrease in the quality of their game" Game designers are not so constrained anymore by the limits of the hardware, unless they want to push boundaries. Quality of a game is not just the most efficient runtime performance - it is mainly a question if the game is fun to play. Do the mechanics work. Are there severe bugs. Is the story cons…

This way of thinking has caused at least a few prominent recurring bugs I can think of.

Texture resolution mismatches causing blurriness/aliasing, floating point errors and bad level design causing collision detection problems (getting stuck in the walls), frame rate and other update rates not being synced causing stutter and lag (and more collision detection problems), bad illumination parameters ruining the look they were going for, numeric overflow breaking everything, bad approximations of constants also breaking everything somewhere eventually, messy model mesh geometry causing glitches in texturing, lighting, animation, collision, etc.

There's probably a lot more I'm not thinking of. They have nothing to do "with the hardware", but the underlying math and logic.

They're also not bugs to "let the programmer figure out". Good programmers and designers work together to solve them. I could just as easily hate on the many criminally ugly, awkward, and plain unfun games made by programmers working alone, but I'll let someone else do that. :)

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#25

Post by bluelightning2k »

Great write up. Thank you. Really great!

I was reminded of the factorio blog. That game's such a huge optimization challenge even by today's standards and I believe works with the design.

One interesting thing I remember is if you have a long conveyor belt of 10,000 copper coils, you can basically simplify it to just be only the entry and exit tile are actually active. All the others don't actually have to move because nothing changes... As long as the belts are fully or uniformly saturated. So you avoid mechanics which would stop that.

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#26

Post by ErroneousBosh »

edflsafoiewq wrote: post #9
applfanboysbgon wrote: post #7

> Imagine a programmer asking a game designer if they could change their formula to use an 8 instead of a 9.5 because it is a number that the CPU prefers to calculate with. There is a very good argument to be made that a game designer should never have to worry about the runtime performance characteristics of binary arithmetic in their life, that’s a fate reserved for programmers Numeric characteristics are absolutel…

Examples?

Going way back into history, the Alesis MIDIVerb reverb unit had a really simple DSP core made out of discrete logic chips. It could add a memory location to an accumulator and divide it by two, invert it, add it and divide it by two, or store it in ram either inverted or not and divide the accumulator by two.

Four instructions, in about eight chips.

By combining shifts and adds Keith Barr was able to devise all the different filter and delay coefficients for 63 different reverb programs (the 64th one was just dead passthrough).

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#27

Post by youarentrightjr »

> The same trick can also be used for the other direction to save a division: NewValue = OldValue >> 3; This is basically the same as NewValue = OldValue / 8; RCT does this trick all the time, and even in its OpenRCT2 version, this syntax hasn’t been changed, since compilers won’t do this optimization for you.

(emphasis mine)

Not at all true. Assuming the types are such that >> is equivalent to /, modern compilers will implement division by a power of two as a shift every single time.

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#28

Post by whizzter »

lefty2 wrote: post #8

> The same trick can also be used for the other direction to save a division: > NewValue = OldValue >> 3; You need to be careful, because this doesn't work if the value is negative. A

Most CPU's has signed and unsigned right shift instructions (left shift is the same), so yes it works (You can test this in C by casting a signed to unsigned before shifting).

The biggest caveat is that right shifting -1 still produces -1 instead of 0, but that's usually fine for much older game fixed-point maths since -1 is close enough to 0.

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#29

Post by lukan »

sublinear wrote: post #24
lukan wrote: post #19

Earlier quoted context omitted.

"and in many cases it is one of many silent contributing factors to a noticeable decrease in the quality of their game" Game designers are not so constrained anymore by the limits of the hardware, unless they want to push boundaries. Quality of a game is not just the most efficient runtime performance - it is mainly a question if the game is fun to play. Do the mechanics work. Are there severe bugs. Is the story cons…

This way of thinking has caused at least a few prominent recurring bugs I can think of. Texture resolution mismatches causing blurriness/aliasing, floating point errors and bad level design causing collision detection problems (getting stuck in the walls), frame rate and other update rates not being synced causing stutter and lag (and more collision detection problems), bad illumination parameters ruining the look th…

Game designer != game engine designer

(But it definitely helps if the game designer knows of the technical limits)

Re: The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

#30

Post by adrian_b »

shakow wrote: post #15
fweimer wrote: post #4

What language is this article talking where compilers don't optimize multiplication and division by powers of two? Even for division of signed integers, current compilers emit inline code that handles positive and negative values separately, still avoiding the division instruction (unless when optimizing for size, of course).

That's what I would have thought as well, but looks like that on x86, both clang and gcc use variations of LEA. But if they're doing it this way, I'm pretty sure it must be faster, because even if you change the ×4 for a https://godbolt.org/z/EKj58dx9T

They use LEA for multiplying with small constants up to 9 (not only with powers of two, but also with 3, 5 and 9; even more values could be achieved with two LEA, but it may not be worthwhile).

For multiplying with powers of two greater or equal to 16, they use shift left, because LEA can no longer be used.

Post reply on HN