[sroerick]

One thing I really don't understand would be the ergonomics of game dev. I mean, I guess it's just an isometric drawing library, and routines for each object (though this obviously isn't OOP game Dev). But like, for example, he talks about simulating the physics of the roller coasters. I get that, and I think I could figure that out in assembly. But, in my head, connecting the dots from simulating the physics to drawing it on the screen is a huge leap. But yeah, having years of background on using assembler for game Dev would obviously be a big part of that equation.

[markus_zhang]

IIRC back then drawing on screen is simply writing into some memory mapped regions. But maybe it is more than that when the game was written, as it was in mid 90s.

I happened to glance over Linux device driver 3e yesterday, and just programming GPIO is ghastly complicated — the programmer needs to request a region, use specific memory in/out functions to write/read, and then release the region, all for just reading and writing some bytes — no real business about.

Not saying that was not a significant feat, but I think it’s almost impossible for anyone to do so nowadays — even with C it is a very good amount of knowledge to write an engine without libraries.