131–140 of 186 posts
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…
> 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 w…
> 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 w…
they will do it for unsigned. for signed they will do a bit more to do the same rounding as C promises
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…
It's a shame that when a Redditor discovered the source code for the original StarCraft "gold master" on a CD, they sent it back to Blizzard in exchange for some fucking blizzard merch [1] EA a while back released the source code to (most) of the old Command & Conquer games [2] though interestingly left out Tiberian Sun and Red Alert 2, StarCraft's closest competitors at the time. Would've been nice for historical pr…
> 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…
> Numeric characteristics are absolutely still a consideration for game designers even in 2026, one that influences what numbers they use in their game designs. The good ones, anyways. I used to think like this, not anymore. What convinced me that these sort of micro-optimizations just don't matter is reading up on the cycle count of modern processors. One a Zen 5, Integer addition is a single cycle, multiplication 3…
A good example of this is using std::vector vs. std::vector in the debug build vs release build.
vector is much slower to access (it's a dynamic bitset). If you have a hot part of the code that frequently touches a vector, you'll see a multiple X slowdown in the debug build.
However, in the release build, there is no performance difference between the two (for me at least, I'm making a fairly complicated game). The cache misses bury it.
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Nuclear_Gandhi From what I heard, there was a Civilization game which suffered from an unsigned integer underflow error where Gandhi, whose aggression was set to 0, would become "less aggressive" due to some event in the game, but due to integer underflow, this would cause his aggression to go to 255, causing him to nuke the entire map. The article says this was just an urban legend thou…
Indeed an urban legend. Sid Meier himself debunked in his memoir, which is a pretty great read.
Weird thing happens. People make up reasons why. One reason is possible. That becomes THE reason, and spread wildly, without confirmation, as an accurate explanation. "Actually that's not true". Now that not being the reason is widely disseminated and if we are lucky the original meme dies out!
But it took 30 years. For a very meaningless rumor.
I had always heard about how RCT was built in Assembly, and thought it was very impressive. The more I actually started digging into assembly, the more this task seems monumental and impossible. I didn't know there was a fork and I'm excited to look into it
OpenRCT2 isn't a fork, it's like OpenTTD, a recreation.
Go look at GDC's Classic Game Postmortems. They have tens of videos of the people who built famous games from the 80s and 90s who often go into technical details of how they do it. For example, Robotron goes into how the code works.
It's remarkably familiar. They basically built object oriented programming and classes using convention only. You treat every actor you want to work with as a chunk of memory with standard layout that includes pointers for behavior and slots for state, and you just try really hard to only operate on the right "Types" at the right places. From there you have your standard game loop of "Get input, update all Actors, render, loop"
The Pitfall postmortem is wonderful. The Atari 2600 had roughly zero RAM to work with, and barely any cartridge space to hold your game. To make their large, somewhat open world, they made each screen built off just a few parameters, and created a bidirectional psuedorandomish function that would generate the parameters on a cycle, giving you a connected map space!