I wonder how common were full game VMs in the 90s. For a game older than myself, wouldn't a VM layer incur a great performance penalty on PCs from that time?
Today we have fewer machines than the great explosive growth of the 80s.
Consider that most 'software' today is JavaScript interpreted by the Web Browser. It's not like those portability concerns didn't exist in the 80s, if anything, it was harder because you had to make your own interpreter back then.
---------
Many (maybe most?) video games seem to have been written in a VM, at least before Doom / high performance 3d graphics.
I think console games were in C/Assembly for performance.
But 'computer' games at that time was before the standard IBM PC or at least, before the PC won and Microsoft achieved dominance. When you didn't know if Amiga, PC98, IBM PC, Mac, or others would win it only made sense to write a VM.
SCUMM (Monkey Island and many others) comes to mind.
I thought most software was MS Excel sheets with interacting formulae :-)
> In most cases, p-code can reduce the size of an executable file by about 40 percent. For example, the Windows Project Manager version 1.0 (resource files not included) shrinks from 932K (C/C++ 7.0 with size optimizations turned on) to 556K when p-code is employed.
> Until now, p-code has been a proprietary technology developed by the applications group at Microsoft and used on a variety of internal projects. The retail releases of Microsoft Excel, Word, PowerPoint®, and other applications employ this technology to provide extensive breadth of functionality without consuming inordinate amounts of memory.
http://sandsprite.com/vb-reversing/files/Microsoft%20P-Code%...
This was not terribly common, for the obvious performance reasons. Another World ran at around 10-20FPS on most of the systems it was released for, which is fine for a methodical game like that (and for adventure games like Monkey Island, etc.) but doesn't work for fast action games.
And of course VM games were basically impossible for the entire 8-bit era, with the exception of things like Zork (and the rest of Infocom's Z-Machine games) whose performance needs were so small that the gigantic overhead of an 8-bit VM was hardly noticeable.
Even into the 16-bit era, the majority of multi-platform games were fully rewritten ports.
Edit: after reading through wikipedia, I think maybe a VM wouldn't be that wasteful, since the game is very simple mechanically.
Computer games had explosive inputs available, like Civilization or needed the use of a mouse.
Not so much action / frame perfect stuff. Not until a bit later anyway. Eventually computers were fast enough for arcade ports but computer games just didn't really target that action niche.
------
The 'computers' with good graphics were like Amiga, not x86 based DOS with mode 13h graphics. So it was all the fallen / failed computers that had the decent action games IIRC.
The opposing idea is represented more by arcade gaming, and later, stuff like Doom and Quake: The game is relatively intimate with the hardware in what it simulates, while the kind of definition that makes up a scene is more on the order of "put a monster here and a health pickup there", which aligns it towards being map data, instead of scripted logic.
The graphics exclusively used real-time rendered polygons with support for transparency, which nobody knew was even possible at the time. Along with researching the new rendering tech, the same person created everything else except the music - the memorable & immersive world, an original story, concept and cover art, strong cinematics that were SoTA at time, graphics and animation, innovative level design, puzzles, the game logic - over just 2 years. It also defined a new 'cinematic platformer' genre, with later titles like Flashback, Blackthorne, Oddworld, and recent LUNARK. It's simply incredible feat.
Aegis Animator was doing pretty much the same sort of rendering on the Amiga, in 1985.
I never did much with it, what with being a kid at the time, but it was fun to play with and looked pretty cool. I don't think its rendering was as tightly optimized as Another World's was, though.
Earthbound (SNES, 1994) contains TWO complete scripting systems, one for the dialog system (which is occasionally used for things it shouldn't be; most of shop logic is in it), and one for scripting sprite movement. The dialog script is actually quite impressive and easy to use; I'd consider implementing a similar system even in a modern RPG. The sprite movement script is trash, significantly harder to work with than games that use raw assembly. Apparently that movement script system was actually a common in-house library at HAL, dating back to the NES era, but I don't know too much about that history.
Also most of the game's assembly was actually compiled from C, which was almost unheard of for console games at the time.
I don’t think virtual machines and emulation are that new of a thing. Virtualizing x86 at full speed on consumer hardware has been a thing for, what, 15 to 20 years? And sure that requires special processor features, but remember that systems that came before that that would need to be emulated had even less computational demands. Iirc, a widely used pos software from the 80s has been running in emulation on pos hardware that far exceeds its requirements for the last 25 years, at least.
Also, my understanding is that lots of crucial government and business software runs on many layers of virtualization.
And my last recollection from what I’ve gathered is that, really until around the mid 90s a lot of operating systems made until then were pretty much hypervisors that ran programs that were virtual machines themselves. Multitasking was simply being able to route hardware resources to a given program, which was sorta its own environment.
https://archive.org/details/byte-magazine-1977-11/page/n147/...
#rightinthefeels