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

71–80 of 186 posts

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

#71

Post by mort96 »

tosti wrote: post #50
mort96 wrote: post #20

Earlier quoted context omitted.

I think Minecraft's lighting system is a good example: there are 16 different brightness levels, from 0 to 15. This allows the game to store light levels in 4 bytes per block. Similarly, redstone has 16 power levels: 0 to 15. This allows it to store the power level using 4 bits. In fact, quite a lot of attributes in Minecraft blocks are squeezed into 4 bits. I think the system has grown to be more flexible these days…

I don't think Minecraft would be considered a cornerstone of optimal programming.

Minecraft is, and always has been, handling vast amounts of data at pretty good performance. It's not an impossibly difficult task, many other people have made voxel game engines which are better, but it's something you can't do without paying attention to these things. Every voxel engine with remotely reasonable performance needs to carefully count bits used per block.

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

#72

Post by troad »

> When reading through OpenRCT2’s source, there is a common syntax that you rarely see in modern code, lines like this:

> NewValue = OldValue I disagree with the framing of this section. Bit shifts are used all the time in low-level code. They're not just some archaic optimisation, they're also a natural way of working with binary data (aka all data on a computer). Modern low-level code continues to use lots of bit shifts, bitwise operators, etc.

Low-level programming is absolutely crucial to performant games. Even if you're not doing low-level programming yourself, you're almost certainly using an engine or library that uses it extensively. I'm surprised an article about optimisation in gaming, of all things, would take the somewhat tired "in ye olde days" angle on low-level code.

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

#73

Post by netcoyote »

Warcraft 1 (1994), Warcraft 2 (1995), and StarCraft (1998) all use power-of-2 aligned map sizes (64 blocks, 128 blocks, and 256 blocks) so the shift-factor could be pre-computed to avoid division/multiplication, which was dang slow on those old 386/486 computers.

Each map block was 2x2 cells, and each cell, 8x8 pixels. Made rendering background cells and fog-of-war overlays very straightforward assembly language.

All of Warcraft/etc. had only a few thousand lines of assembly language to render maps/sprites/fonts/fog-of-war into the offscreen buffer, and to blit from the offscreen buffer to the screen.

The rest of the code didn't need to be in assembly, which is too time-consuming to write for code where the performance doesn't matter. Everything else was written in portable assembler, by which I mean C.

Edit:

By way of comparison, Blackthorne for Super Nintendo was all 85816 assembly. The Genesis version (Motorola 68000) and DOS version (Intel 80386) were manually transcribed into their respective assembly languages.

The PC version of Blackthorne also had a lot of custom assembler macros to generate 100K of rendering code to do pixel-scrollable chunky-planar VGA mode X (written by Bryan Waters - https://www.mobygames.com/person/5641/bryan-waters/).

At Blizzard we learned from working on those console app ports that writing assembly code takes too much programmer time.

Edit 2:

I recall that Comanche: Maximum Overkill (1992, a voxel-based helicopter simulator) was written in all assembly in DOS real mode. A huge technical feat, but so much work to port to protected mode that I think they switched to polygon-rendering for later versions.

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

#74

Post by evandale »

The pathfinding section reminded me that there's a YouTube steamer, Marcel Vos, who goes into a deep dive of how the pathfinding works.

https://youtu.be/twU1SsFP-bE

He has lots of videos that are deep dives into how RCT works and how things are implemented!

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

#75

Post by Rendello »

troad wrote: post #72

> When reading through OpenRCT2’s source, there is a common syntax that you rarely see in modern code, lines like this: > NewValue = OldValue I disagree with the framing of this section. Bit shifts are used all the time in low-level code. They're not just some archaic optimisation, they're also a natural way of working with binary data (aka all data on a computer). Modern low-level code continues to use lots of bit s…

I learned these low-level bit tricks by reading TempleOS' HolyC source code. I remember feeling like a genius when I worked out what this line does:

dc->color=c++&15;

Hint: it's from this "Lines" demo program, whose source is here: https://web.archive.org/web/20180906060723/https://templeos....

And this is what it looks like when it runs (ignore the fact it's running in Minecraft): https://youtu.be/pAN_Fza6Vy8?t=38

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

#76

Post by Pannoniae »

helterskelter wrote: post #70
Pannoniae wrote: post #58

Earlier quoted context omitted.

Hey, this isn't entirely accurate! The 4-bit stuff is a hangover from Notch doing this (I'd maybe even say a similar-calibre programmer to Chris Sawyer...). The sound has nothing to do with technical limits, that's a post-facto rationalisation. The game never played midi samples, it was always playing "real" audio. The style was an artistic choice, many similar retro-looking games were using chiptune and the sorts. I…

Fair enough, I mostly meant to point out some of those design decisions predate MS, as much as I love to hate on them. The music was just an interesting bit of trivia I read the other day.

Yeah, 100% :) Ironically, the design constraints are one of the big things which made it work so much! If it was designed in a "traditional" way, it would have been much less ambitious.

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

#77

Post by Cpoll »

plopz wrote: post #45
bluelightning2k wrote: post #25

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 becau…

I was pretty disappointed with how Factorio reworked how fluids worked in the expansion. The old system had its quirks and the new system is obviously more performant, but it throws realism out the window which is a bummer.

I don't miss it. I also found Satisfactory's old fluid system (with concepts like sloshing) wildly unintuitive. I'll go so far as to say that accurate fluid dynamics is detrimental to any game that's not about beavers and water table management.

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

#78

Post by maxglute »

Is there a place to find stories of recent game optimization? What's most ridiculous on like quick inverse square route. As someone who spent way too much time vraying in prior life, I still can't believe we got real time ray tracing.

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

#79

Post by DougN7 »

WalterBright wrote: post #64
ryandrake wrote: post #40

Earlier quoted context omitted.

Back in the early, early days, the game designer was the graphic designer, who also was the programmer. So, naturally, the game's rules and logic aligned closely with the processor's native types, memory layout, addressing, arithmetic capabilities, even cache size. Now we have different people doing different roles, and only one of them (the programmer) might have an appreciation for the computer's limits and happy-p…

I wrote the Intellivision Mattel Roulette cartridge game back in the 1970s. It was all in assembler on a 10 bit (!) CPU. In order to get the game to fit in the ROM, you had to do every feelthy dirty trick imaginable.

I would love to hear more about that.

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

#80

Post by quietsegfault »

netcoyote wrote: post #73

Warcraft 1 (1994), Warcraft 2 (1995), and StarCraft (1998) all use power-of-2 aligned map sizes (64 blocks, 128 blocks, and 256 blocks) so the shift-factor could be pre-computed to avoid division/multiplication, which was dang slow on those old 386/486 computers. Each map block was 2x2 cells, and each cell, 8x8 pixels. Made rendering background cells and fog-of-war overlays very straightforward assembly language. All…

Maximum overkill was an amazing game. I probably played hundreds and hundreds of hours.
Post reply on HN