Hacker News Reader

Comment by ssl232 | Hacker News Reader

Transport Tycoon Deluxe and Rollercoaster Tycoon were famously programmed in assembly by Chris Sawyer, essentially on his own. I recall they worked on my Pentium 166 practically without issue, even with large maps; perhaps only a tiny bit of lag when zooming out to view the whole thing. They've since been unofficially rewritten in C++ [1, 2].

[1] https://www.openttd.org/ [2] https://openrct2.org/

View on HN

http://www.chrissawyergames.com/faq3.htm

His site's still up!

> What language was RollerCoaster Tycoon programmed in?

> It's 99% written in x86 assembler/machine code (yes, really!), with a small amount of C code used to interface to MS Windows and DirectX.

I am not really familiar with assembly, I only tried it once, but a game in assembly seems a little too complicated!

Everything used to be, one of the reasons for CISC instruction sets is the complex instructions do many things at once, which is very convenient for programmers. An assembly instruction becomes more like a function call that does several low level things. Sure CISC assembly is more complex, but if your are an experience programmer those complex instructions do things that you find very useful and make your program more maintainable. Part of the problem with modern assembly is new instructions have been shoe-horned into existing CPU designs instead of elegantly designed in from scratch, the fact that they had to fit those instructions in meant that compromises had to be made.

Today there is no point. Optimizing compilers have gotten very good, and while it is still possible for hand tuned assembly to beat compiled code, with compiled code you change a flag and your code is optimized better for some other CPU that the hand tuned code for a different but compatible CPU. Then change a flag again and your code runs on a completely unrelated CPU family.

I started game development around the Gameboy Color days and everything was in assembly. Every other platform had shifted to C/C++.

It wasn't bad actually. We had macros to do 16 bit work with 8 bit registers, etc. so the code was much more high level than it sounds. We did have to be very careful with the stack (making sure it's balanced), but otherwise very similar to coding in C.

With modern architectures, I much prefer C and intrinsics and let the compiler deal with it (and nudge it when it gets it wrong).

Almost all console and microcomputer games were assembly until well into the 80s. Atari 2600 games, for example, had 2kb of ROM and 128 bytes of memory. Careful handcrafting was required not only to get the game to fit in the cartridge but to "race the beam": reprogramming the sprite registers as the image was generated, line-by-line, to achieve more sophisticated graphics.

(Original Spacewar was PDP-11 assembly. Original Colossal Cave appears to have been FORTRAN.)

Gotta say that was a bad choice even then.

By what measure? It's a great game, that people still talk about, ran more smoothly than a lot of current title. And it sounds like he knew the language. So how was this a bad choice?

He could’ve gotten essentially equivalent performance writing it mostly in C, with only the time-critical parts in assembly. Assuming equivalent knowledge of C, it would’ve been quicker to write, easier to update and port, and easier for others to work with the code.

Not to sound rude, but this mostly seem like "random" assumptions, even on the goals side.

Was there others to work on the code? Was portability a goal? Would it matter if the interface is a C for DirectX anyways?

You don’t sound rude. These assumptions are common for games in general, but who knows what the assumptions were for this game in particular? Or whether this programmer knew C well at the time? Or if Microsoft was likely to ask for ports or updates?

Maybe. Maybe not. The C compilers back then were not as good at optimising machine code as modern C compilers are.

It was possible: profile your program to find the hotspots, rewrite those in assembly, rinse and repeat.

Bad choice that netted Chris a bunch of money and made iconic games. It's not stupid if it works.

Totally. The sausage factory makes delicious sausage, but you might not want to see inside!

Have you ever programmed in assembly? Code that I wrote 20 years ago in Motorola 68000 assembly is easy to read and understand for me today. While I have seen “modern” code written in modern languages (by other people) that made me want to throw up and/or throw things at those people :)

Yes, though not for a long time now. 68000 was actually some of the hardest for me to deal with, when folks would creatively use EVERY register…and in a different way in each procedure.

But of course you are right, good and bad code has been written in every language. And guess what folks, your code is NOT “self-documenting,” you’re just being lazy by not writing comments! OK, soapbox ended! :-)

> good and bad code has been written in every language

Yes indeed. There seems to be no limit to how bad code can be written in any programming language :)

My Prof. once said that the only difference between writing assembly and coding in a high-level language is that you have to type more.

And that opinion would probably turn grey on HN. At best, it's a not-so-funny joke.

That is technically correct. Which is the best kind of correct.

Reply on news.ycombinator.com