Differences

This shows you the differences between two versions of the page.

--- vc-1 [2025/11/30 16:13] – appledog
+++ vc-1 [2025/12/05 02:26] (current) – appledog
@@ Line 1: / Line 1: @@
-= Virtual Computer 1
+= VC-1
-This page describes the VC1 project.
+**Virtual Computer 1**
+This page describes the VC-1 project.
 == History
-I like NetHack and roguelike games, so one of the first things I do to ease myself into a new computer language is to write a sort of roguelike game. The game I write is called NetWhack. I first wrote NetWhack in C++ in 1997. By 1999-2000 I had rewritten the project in Java. After essentially completing the game to my own satisfaction it was placed on the back burner.
+I like NetHack and roguelike games, so one of the first things I do to ease myself into a new computer language is to write a sort of roguelike game. The game I write is called NetWhack. I first wrote NetWhack in C++ in 1997. By 1999-2000 I had rewritten the project in Java. After teaching Python for a while, I eventually wrote it in Python. Then I rewrote it in Java again using LWJGL. After essentially completing the game to my own satisfaction it was placed on the back burner. You see, there was a serious problem that prevented me from updating the game using a modern library like LWJGL or re-writing in JavaScript.
-In 2018, 2019 and 2020 I was teaching Python and Javascript to Neo, Roger, and a few other kids. Eventually we came to the need for a sort of JavaScript terminal/basic game-loop that we could use as a foundation for our projects.
+It was the old problem of blocking IO that I had with game libraries like LWJGL: **because it is event driven, you cannot perform blocking input.** Or rather I should say, because LWJGL (and JavaScript) are extremely poorly designed, you can't normally do blocking input. I asked around for years and no one ever had a solution. I was told to just accept the sign of the times and get with the paradigm of event-driven programming.
-There was, however, one serious problem. It was the old problem of blocking IO that I had with game libraries like LWJGL: **because it is event driven, you cannot perform blocking input.** Or rather I should say, because LWJGL (and JavaScript) are extremely poorly designed, you can't normally do blocking input. However, nature always finds a way; In Java, I just made a new "thread" and handled a custom keyboard buffer there. This was a very technically difficult thing to do, but it worked, and I had what amounted to blocking input under LWJGL.
+What follows is an interesting story; it's so interesting I'll skip it and just say I spent years trying to figure out how to do blocking input in JavaScript. I went through many revisions of many games and programs in various langauges. I knew there must be a way. One day, I had an epiphany and figured out how to do it. It was during the development of a small demo program I wrote called "Javascript Terminal technical Demo".
-== Blocking Input in Javascript
+You already know the story, here is the code.
-The story of VC-1 is the story of the JavaScript version of our PyGame base code morphing over time, and me banging my head against a wall for years trying to figure out how to do blocking input in JavaScript. I went through many revisions of many games and programs in Python and Javascript. However, one day, I had an epiphany and figured out how to do it. It was during the development of a small demo program I wrote called "Javascript Terminal technical Demo".
-What remains is the story of JTTD, which eventually became ensconced as VC-1.
 * [[JavaScript Terminal]]
@@ Line 21: / Line 20: @@
 **1. It's really a CPU.** A monolithic atomic queue is a CPU. When I realized this I stopped working on NetWhack in Javascript. I realized I needed a much better "Javascript Terminal" and possibly something with a much stronger terminal simulator. I started getting sucked into creating variables in the state machine and so forth and the whole thing became just a little messy. I took my time but it never really worked.
-However, the concept DID work and the mistake, I realized, was trying to do it 50-50. I took a long, hard look at web assembly.
+However, the basic concept DID work and the mistake, I realized, was trying to do it 50-50. I took a long, hard look at web assembly. The thing with Web Assembly is you don't have access to the DOM. Well, you have to write wrapper functions. For some reason I didn't want to go back to C/C++ or try to compile the Java code into web assembly. I wanted to go full retard. This is after all, a pet project. Hmm, PET project?
+I was directly inspired by the best line in Star Trek Voyager:
+<blockquote>When I think about everything we've been through together, maybe it's not the destination that matters, maybe it's the journey, and if that journey takes a little longer, so we can do something we all believe in, I can't think of any place I'd rather be or any people I'd rather be with.<cite>--Ensign Harry Kim</cite></blockquote>
-The thing with Web Assembly is you don't have access to the DOM. Well, you have to write wrapper functions.
 After a long time meditating about all of this I started [[VC-2]]. It was a rabbithole of unforseen consequences. Visit [[VC-2]] next.