Dynamic Subspace

Tag: retrocomputing

Enjoyed Alien: Romulus Despite Too Damn Loud IMAX and Other Customers Who Were Annoying

Yesterday, Y and I took the subway to Manhattan to watch the film Alien: Romulus on the IMAX screen at the AMC 14 on 34th Street.

I thought that Alien: Romulus was an interesting story that threaded the needle of connecting the origin film Alien (1979) via the first Xenomorph we saw and the android Ash (Ian Holm) to Prometheus (2012) and Alien: Covenant (2017) via the black liquid (hints of the black oil from The X-Files) and the Engineers. The retrocomputers, ASCII text, and a computer with a 3.5″ floppy disk drive made it feel like the same world as Alien. I felt that some of the lines were corny, over-the-top, and unnecessary fan service, but overall, it was an interesting and sometimes exciting addition to the series.

Unrelated to the film per se, I have some thoughts instead about the technologies of presentation and communal engagement with the film.

First, movies shown in theaters, especially IMAX films, are shown with the volume far too loud. Y and I last went to an IMAX film over 10 years ago, but the memory of how that experience hurt both of our ears, we planned ahead and brought foam ear plugs. Even with our ear plugs, which work wonders at eliminating noise in other settings, were just barely up to the task of keeping the volume of the film presentation at tolerable levels. Let me put that another way: While wearing ear plugs, I was able to hear the film’s dialog and sound effects and music just fine and sometimes a little not fine when it got so loud as to overpower the ear plugs. That’s too damn loud. It was only after we were leaving that Y thought we should have checked the decibel levels. Hindsight is 20-20.

Second, I know to some I might sound like an old man yelling at kids to get off my lawn, but for those who have known me a long time, they know that I’ve been deadly serious about this since going to see films when I was a kid. That is we owe other theater goers our respect so that everyone can enjoy the film. Carrying on, talking, or using a phone during a movie can disturb others, so we shouldn’t do those things. Unfortunately, some of the other customers, who would have paid the same $30 per ticket we paid, don’t care for social norms and simple decency. It would be one thing if these were kids who didn’t know any better, but these were adults who acted like kids. Hell is other people, I suppose.

Considering these things, I prefer to stay at home to enjoy a film without ear plugs or annoying guests. Of course, I am assuming the neighbors don’t act the fool, which I’ve tried my best to address following these tips.

August 23, 2024
Blue Polygonal Sculpture in Manhattan Titled “Jean-Marc”

This blue sculpture looks like a blue polygonal figure that has stepped out of a mid-1990s Playstation game. The sculpture is called “Jean-Marc” and was made by Xavier Veilhan. It’s located in Manhattan near MOMA.

August 15, 2024
Introduction to Piet Mondrian’s Neoplasticism Through Star Trek: The Next Generation

In “The Offspring,” the 16th episode of the third season of Star Trek: The Next Generation, we get to see Piet Mondrian’s “Tableau I” hanging on the wall of his quarters when he shows it to his daughter Lal. I think this might be the first time that I had really seen or had my attention drawn to a work by Mondrian. I thought it was quite striking as a work of art, and it seemed fitting that Data might be drawn to this work for its ordered lines despite Mondrian’s neoplasticism theory and its connection to nature and emotion as being the motivators for the artist’s composition.

Mondrian’s “Tableau I” appears in Lt. Cmd. Data’s quarters–notably in the eleventh episode of season five titled “Hero Worship,” in which Timothy, a young boy traumatized by the loss of his parents, apes Data’s mannerisms in order to erase his emotional response to his loss. In one scene, Data and Timothy paint in Data’s quarters where “Tableau I” is on an easel to the side.

In the Star Trek: The Next Generation Interactive Technical Manual, Mondrian’s “Tableau I” is on an easel in about the same place as pictured in “Hero Worship.”

Yesterday, I was able to see some of Mondrian’s works in person at the Museum of Modern Art (MOMA) in Manhattan. Y and I went there to see our friends from Japan, Masaya and Saki. While I didn’t get to see “Tableau I,” because it hangs in the Kunstmuseum in The Hague, I did get to see some representative works of his neoplasticism.

August 13, 2024
Mark V. Shaney v1.0, a Probabilistic Text Generator for MS-DOS

Of the text generators that I’ve discussed this past year, Mark V. Shaney v. 1.0 (MARKV.EXE) is by far the simplest to use but it is also one of the most advanced due to its implementation of weighted probability tables (Markov chains–the program’s name is a pun on this) that underpin how it generates text. I was able to obtain a copy from the TextWorx Toolshed archived on the Internet Archive’s Wayback Machine.

MARKV.EXE (44,365 bytes) was developed in 1991 by Stefan Strack, who is now a Professor of Neuroscience and Pharmacology at the University of Iowa. In the MARKV.DOC (10,166 bytes) file that accompanied the executable, Strack writes, “Mark V. Shaney featured in the “Computer Recreations” column by A.K.Dewdney in Scientific American. The original program (for a main-frame, I believe) was written by Bruce Ellis based on an idea by Don P. Mitchell. Dewdney tells the amusing story of a riot on net.singles when Mark V. Shaney’s ramblings were unleashed” (par. 2). Dewdney’s article on the MARKV.EXE program appears in the June 1989 issue of Scientific American. The article that Strack mentions is available in the Internet Archive here. A followup with reader responses, including a reader’s experiment with rewriting Dewdney’s June 1989 article with MARKV.EXE, is in the January 1990 issue here.

The program works by the user feeding a text into MARKV.EXE, which is “read.” This generates a hashed table of probabilistic weights for the words in the original text, which can be saved. The program then uses that table and an initial numerical seed value to generate text until it encounters the last word in the input text or the user presses Escape. The larger the text (given memory availability) , the more interesting its output text, because more data allows it to generate better probability weights for word associations (i.e., what word has a higher chance to follow a given word). Full details about how the program works can be found in the highly detailed and well-organized MARKV.DOC file included with the executable.

Using DOSBox on Debian 12 Bookworm, I experimented by having MARKV.EXE read William Gibson’s “Burning Chrome” (1982). I pressed “R” for “Read,” entered the name of the text file (bchrome.txt), and pressed enter.

The program reported “reading” for a few minutes (running DOSBox at default settings).

After completing its “reading,” the program reported stats on the table that it created using bchrome.txt: 9167 terms (608,675 bytes).

I pressed “G” and the program began to generate text based on its table of probabilities generated from the bchrome.txt text file, which contained the short story, “Burning Chrome.” While the generated text flows across the screen, there are options to press “Esc” to stop or any other key to pause.

After it completed writing the generated text to the screen, I pressed “S” to save the generated text and it prompted me to type in a file name for the saved generated text: gibson.txt.

Pressing “S” gives the user an option to save the table for future use. I went with the default name, MARKKOV.MKV (not to be confused with a modern Matroska container file). This file can be loaded in MARKV.EXE on subsequent runs by pressing “L” and entering the name of the table. When the user presses “Q”, the program exits back to DOS and displays a message, “The random number seed was x,” where x is a random number used in the generation of text. If repeatability is important to the user, you’ll want to make a note of that number and use it with the -s modifier when running MARKV.EXE again (e.g., markv.exe -s2510).

Mark V. Shaney’s implementation of a Markov chain that builds a table of next word probability on a small text sample is one example of the predecessors to large language models (LLMs) like LLaMA and ChatGPT. However, Mark V. Shaney’s word association probabilities is far simpler than the much more complicated neural networks of LLMs (especially considering attention) with many orders of magnitude more parameters trained on gargantuan data sets. Nevertheless, Mark V. Shaney is one aspect of the bigger picture of artificial intelligence and machine learning development that led to where we are now.

August 6, 2024
kkrieger, a First Person Shooter From the Demoscene That’s Only 96K
In 2004, .theprodukkt, a project aiming to use “generative computer graphics” and “procedural content creation,” developed a demoscene-inspired first person shooter (FPS) called .kkrieger that features a complex 3D environment with lighting and shadow effects, a variety of enemies, a selection of weapons, an atmospheric soundtrack, and engaging sound effects. Incredibly, .kkrieger is an astonishingly small 96K! The game uses a clever procedural approach to recreate its main elements at runtime instead of storing those assets in an appropriate file format that would balloon the game’s installation.

To put .kkrieger’s tiny file size in perspective, consider that Wolfenstein 3D (1992) is 1.3MB installed, Doom (1993) is 4.6MB, Quake (1996) is about 700MB (including its audio CD soundtrack), Unreal Tournament (1999) is about 780MB, Halo: Combat Evolved (2001) is about 700MB, and Half-Life 2 (2004) is about 6GB. Put another way, many of the in-game screenshots that I made and attached to this post in JPEG format are about the same size or larger than the entire kkrieger game!

To accomplish this feat, .theprodukkt designed the game to run on high-end PC hardware of that era on Microsoft Windows with DirectX 9.0b:
```
.kkrieger requires a relatively high-end machine to run properly. To be
precise: 

- A 1.5GHz Pentium3/Athlon or faster.
- 512MB of RAM (or more)
- A Geforce4Ti (or higher) or ATI Radeon8500 (or higher) graphics card
  supporting pixel shaders 1.3, preferably with 128MB or more of VRAM.
- Some kind of sound hardware
- DirectX 9.0b 
```
In the readme.txt included with the game’s executable, .theprodukkt explains the technical details for .kkrieger:
```
  In general, if you have any technical questions concerning .kkrieger, either refer to our web site or contact us via email. However past experience shows that there are some rumours and misunderstandings about our work that are very hard to correct, so we'll state the truth here, in written form, for all the world to see :) 

- We do .not. have some kind of magical data compression machine that is able to squeeze hundreds of megabytes of mesh/texture and sound data into 96k. We merely store the individual steps employed by the artists to produce their textures and meshes, in a very compact way. This allows us to get .much. higher data density than is achievable with normal data compression techniques, at some expense in artistic freedom and loading times.
- .kkrieger is not written in 100% assembler/machine language. Not even nearly. Like the vast majority of game projects being developed today, .kkrieger was mostly written in C++, with some tiny bits of assembler where it is actually advantageous (notably, there are a lot of MMX optimisations in the texture generator). 
- A kilobyte is, historically, defined to be 1024 (2^10) bytes, not 1000. Thus .kkrieger is a game in 96k even though it's actually 98304 bytes. 
- The concept of the texture/mesh generators was developed by fiver2. We do .not. want to claim that the techniques we used to develop .kkrieger are new inventions. It´s rather a  selection of useful operations and their parameters to optimise the results. 
```
For this post, I ran .kkrieger on my Ryzen 7 5800X system (NVIDIA RTX 3090 Founder’s Edition, 128GB DDR4 RAM) with 32-bit Wine 8.0-repack-4 for Debian with it set to run in an emulated 1024×768 desktop (to avoid it resetting my display settings and make it easier to capture game play using OBS Studio. It ran smoothly without any glitches. However, it did freeze once during a sequence of running it multiple times. After closing Wine, it successfully ran on the next try. You can download a copy from the link in the first paragraph that leads to a cached copy of the official website in the Internet Archive’s Wayback Machine.
July 30, 2024