Differences

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

--- javascript_terminal_v3 [2023/11/30 02:37] – appledog
+++ javascript_terminal_v3 [2025/12/05 02:36] (current) – appledog
@@ Line 35: / Line 35: @@
 Note that if we are in a multi-threaded environment we can always have the game engine running in an off-UI thread. Or the implementation can launch copies in their own threads vs, manual task and context swithching which you would need to simulate in an (ex. JavaScript) implementation. But it would be transparent to the code written for the virtual machine.
-== It's really a CPU
+== It's really an interpreter
-A monolithic atomic queue is like a CPU. Since we don't have a ROM, we write high level commands in JavaScript. Slowly, we can implement opcodes and start working more with the state machine.
+Like BASIC. The whole thing with INPUT and SET_NAME feels like you are writing your own programming language and interpreter. But on top of that, there's the actual BASIC interpreter which works exactly the same way:
 === BASIC Interpreter
@@ Line 53: / Line 53: @@
 </Code>
-Instead of refactoring into a state machine, I threw together a quick BASIC class which processed commands in a program[] array. It handles print, and goto. Since it is a quick design it can not handle infinite loops or very long programs, since there is no time for the game loop to process updates and render or for the UI to make those changes to canvas.
+Instead of refactoring into a state machine, I threw together a quick BASIC class which processed commands in a program[] array. It handles print, and goto. Since it is a quick design it can not handle infinite loops or very long programs, since there is no time for the game loop to process updates and render or for the UI to make those changes to canvas. Then I realized... refactor into a state machine? Did I even realize what I had just said?
-However, for the point of theory, yes, it is possible to write a scripting language (or a CPU simulator) and have it run in the terminal.
+== It's really a CPU
+A monolithic atomic queue is kind of like a CPU. Since we don't have a ROM, we write high level commands in JavaScript. Slowly, we can implement opcodes and start working more with the state machine.
+This kind of blew my mind at the time so I took a lot of time off from the project thinking about it.
+== Aside
 ==== Jump Table in JavaScript
 <Code:JavaScript>
@@ Line 97: / Line 101: @@
 In a real VM, the code would not be stored in a program[] array but in memory[] and read from there by the interpreter. There are lots of little design clashes between the idea of a VM, the idea of a Game (NetWhack) and the idea of s hybrid scripting language written in Javascript. They are not really compatable. So for a V4 the goal will be to pare down and really isolate the functionality of Terminal, and to clean up main by making a class Screen, and also perhaps a class Keyboard, class Mouse, etc.
-== Bugs
-Well, there are still a few 'bugs' but maybe they are just quality of life fixes. I'd like the terminal to retain it's cursor y position, if possible, during a resize -- or, to clear the screen of existing text. Frankly it isn't important enough for me to worry about right now, and it probably isn't really a true bug, so I will leave it for now.
 == Final Thoughts
 Today's computers are many millions of times faster than (ex. a C64). Even a C65 running at 3.5mhz can 'software' simulate a C64. People have written Sega Master System (Z80) system simulators on 386 quality systems. The point is that today's processors are in many cases over a million times faster than a C64 or 8086 style processor and are overkill for this. Therefore if we move in the direction of a full cpu and system simulator the main problem will not be processing speed, but writing the software. We don't have a ROM/BIOS and we don't have an OS, and those two are both rabbitholes greater than or equal to a 'JavaScript NetWhack'. It's just a little too big to deal with before we write the game.
-== The Future of JTTD
+As it stands, V3 is a sort of kludge, filled with stop-gaps. I will need time to think over everything I have learned, and one day, approach V4 from a different direction.
-V4 will be whatever we do to support NetWhack, and then a pared down version will be presented as a V5 "final". It will represent a programmable terminal emulator slash game engine for character mode programs. Future goals would be for some interactive fiction games, or other interesting games, and possibly, as a platform for teaching JavaScript in a familiar environment (using the terminal as a codebase, and running everything in a Game class. Like modern Android design for example.) For now though, V3 is a sort of stop-gap kludge, and the rewrite will be coming after JavaScript Netwhack.
+(--Me, in 2022).