Differences

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

--- javascript_terminal_v3 [2023/11/30 02:27] – appledog
+++ javascript_terminal_v3 [2023/11/30 02:37] (current) – appledog
@@ Line 39: / Line 39: @@
 === BASIC Interpreter
+<Code:BASIC>
+PRINT A
+GOTO 40
+PRINT B
+PRINT C
+PRINT D
+LIST
+RUN
+A
+C
+D
+</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.
@@ Line 75: / Line 89: @@
     }
 }
+</Code>
 This example is how to support a large number of opcodes/commands quickly.
 == Refactoring Needed
-V3 is V2 but with changes made in how terminal is controlled by the main program. The error of processing commands in the terminal was addressed with the BASIC class. The same idea needs to be made with an OS or TerminalCommands class, to separate that functionality out of the Terminal class. The Terminal class is only supposed to maintain and possibly draw the terminal -- and actually the draw code might be removed into a class that maintains canvas as a virtual 'screen' object -- like in Java NetWhack where there was a Screen and a Terminal class.
+V3 is V2 but with changes made in how terminal is controlled by the main program. The code has also become somewhat spaghetti. I partially addressed this by removing the Tile class from V3 and adding BASIC command processing into its own class. But much more work needs to be done on this. The BASIC class should maintain the copy of the program code, and the Terminal class might need to offload it's draw funcion to a Screen class. We might even move event checking into an OS or CPU class. Or both. But the OS class would eventually be replaced by programs running on the CPU (a ROM).
-The code has also become somewhat spaghetti. I partially addressed this by removing the Tile class from V3 and adding BASIC command processing into its own class. But much more work needs to be done on this. The BASIC class should maintain the copy of the program code.
+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.
-And, 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