javascript_terminal_v3
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| javascript_terminal_v3 [2025/12/05 02:33] – appledog | javascript_terminal_v3 [2025/12/05 02:36] (current) – appledog | ||
|---|---|---|---|
| Line 36: | Line 36: | ||
| == It's really an interpreter | == It's really an interpreter | ||
| - | Like BASIC. The whole thing with INPUT in v2 feels like you are writing your own programming language and interpreter. But on top of that, there' | + | Like BASIC. The whole thing with INPUT and SET_NAME |
| === BASIC Interpreter | === BASIC Interpreter | ||
| Line 53: | Line 53: | ||
| </ | </ | ||
| - | 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. |
| == It's really a CPU | == 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. | 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 | == Aside | ||
| Line 99: | 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. | 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 ' | ||
| == Final Thoughts | == Final Thoughts | ||
javascript_terminal_v3.1764902026.txt.gz · Last modified: by appledog