Differences

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

--- javascript_terminal_v3_rant [2023/11/24 06:15] – appledog
+++ javascript_terminal_v3_rant [2023/11/29 01:03] (current) – appledog
@@ Line 1: / Line 1: @@
-= JavaScript Terminal V3 Rant
+[[JavaScript Terminal v3]]
-Based on the ideas I came up with trying to write NetWhack in different languages and environments I hit upon the idea of having the game itself start out as a terminal simulator, and then writing the game engine to operate as a sort of thing, inside the environment of the terminal simulator.
-I found that if I chopped up the logic in a more granular way, I could achieve effects like string input.
-But as I developed this system more and more what I started to understand was that I had invented some kind of new computer language, and I was actually programming in (JavaScript)+new language to get things done that JavaScript couldn't do on it's on. I began to realize that if I continued along this path what I was going to end up doing is writing a virtual machine and then writing the game in that machine.
-Actually, I started to realize that is not such a bad idea.
-The game is already kind of running in a virtual machine, the terminal emulation side of the program. Why not fully embrace it?
-Today's computers are many millions of times faster than a C64, but even a C64 (6502 processor) can run Linux. Even an 8086 can run Minix. Yeah, I never tried it, but the point is that today's processors are over 100,000 times faster than a 486 and that's ignoring more efficient instructions, more efficient instructions per cycle, and multithreading. Even if I just wrote a whole new VM from scratch it would run fast enough for any kind of yesteryear game. I mean, look at modern emulators. You can do dreamcast at 60fps on anything these days.
-Yeah it's a lot of work, but not as much as you might think. And the re-usability... the chance to do things right this time, like it was the first time...
-== Perspective
-I could move from the bottom up, the top down, or the middle. Bottom up is writing a machine from scratch then writing an os for it, then writing tools, then writing netwhack in it. This would mean netwhack would run the same on any hardware forever. That's kind of cool, it's also a contribution to the community in terms of reusability. But I could also go from the top down, and just keep adding state, adding state, and breaking things up, until I have achieved almost the same thing.
-For example I could have a class called 'terminal state' (i.e. Screen vs. Terminal in Java Netwhack). Sure that is something I need to do to fix an entire class of bugs in Terminal. But carrying the idea further I can have a Class CombatState. Then combat between two entities can be a "thread" which runs and has its own event queue (i.e. thread) which works on its own context. By event queue there is the main event queue, and then others such as io, and so forth. And the system is responsible for switching between all these different queues, allowing them to access their own contexts, and so forth. It's like how i wrote terminal. There is a function called leftarrow(). It performs the actual action. But deciding when to call it (and so forth) is done via program logic. Well, what if leftarrow() (or, arrowleft()) -- was a cpu instruction? And what if the logic to call it was abstracted (chunkified? quantized?) into other cpu instructions? Well, let's not call them cpu instructions just yet, let's call them function calls.
-And I just keep abstracting and refactoring until I get a bunch of function calls that look like CPU instructions. At least to the point where the script I have essentially written allows me to do
-<Code:BASIC>
-A = INPUT()
-IF (A == 'Q') THEN GOTO 3000
-C = GETKEY()
-</Code>
-And what I have basically done, pun intended, is invent some kind of BASIC.
-<Code:BASIC>
-STORE C
-CALL GETKEY
-GET C
-IF C IS ABOVE 90 GOTO 10
-</Code>
-Whats with the 10, 20, 30? They're array indexes, duh. Makes things easier.
-The point is, that there are many contexts. Suddenly I can fork(). In Javascript. But it runs in a single thread.
-I would have to re-implement print. But I have already grokked the logic of puts, etc. as shown not just in Java Netwhack but JavaScript Terminal Demo v2. This can be done. And once I have written it (i.e, written stdlib for the machine) truly amazing and beautiful things could happen.
-== Web Assembly
-What about Emscripten? You can compile C/C++ for JavaScript!
-Yeah, but you can't fork(), you can't getkey(), and you can't access the DOM. These problems are trivial in my imagined CPU in a JavaScript Box.
-Web Assembly is an utter failure and it was designed to be a failure.
-This isn't even a plugin. I don't need anyone's permission for this. It's a javascript interpreter that uses canvas and whatever and everything else is given as a text program (or a compiled bytecode). omg its perfect. It even has a watermark.