Differences

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

--- javascript_terminal_v2 [2023/11/22 04:53] – appledog
+++ javascript_terminal_v2 [2023/11/27 04:51] (current) – appledog
@@ Line 22: / Line 22: @@
 This separation of terminal mode and command move is central to the goal of escaping the limitations of JavaScript. We do this by creating the nucleus of a state machine and atomizing the execution of instructions inside the context of that machine. This is the 'VM idea'.
+=== the input() connundrum
+After I published technical demo 2 (this) I added an input() function, which led to a realization that there was no need to use state to operate the game in two modes; what was really required were a series of flags such as 'echo' (echo on, echo off), and hooks where a game could read those keystrokes. In fact, this contributes towards the 'VM idea' (see below).
+I did retroactively add input() to technical demo 2 (see commands HELP and INPUT). String input in the form of an input() function works by giving the system the KEY which will identify the event-command, and a prompt string. The prompt string can be empty and no prompt string will be shown; Calling this loses program context so processing will effectively end after the input command is given. This works as follows; the user enters a 'change name' command. The program then calls
+<Code:JavaScript>
+    input("SET_NAME", "What is your name? ");
+    return;
+</Code>
+Then, when the user presses ENTER, an event will be added to the queue which looks like this:
+<Code:JavaScript>
+    SET_NAME Richard
+</Code>
+Then, the game engine will handle this event by changing the user's name. In theory, the game engine will set the name before the next user event is called, either by having a priority queue for state changes, or by assumption (i.e. fiat) that there is no command in the queue which relies on SET_NAME. If so, the system could be programmed to HALT until SET_NAME executes (SET_NAME would be added and the system would wait until it changed to SET NAME <value>).
+What if multiple contexts are required; such as, asking three questions in a row? Then, multiple events could be added to the queue:
+<Code:JavaScript>
+    INPUT SET_NAME What is your name?
+    INPUT SET_CLASS "What is your class (Fighter, Mage)?
+    INPUT SET_RACE "What is your race (Human, Elf, Hobbit)?
+</Code>
+The engine can then throw an INPUT command, and since event processing stops during INPUT, the next question will be asked once the previous one is answered.
+What if you need to control state? then you can add queue commands such as:
+<Code:JavaScript>
+    SET_NAME
+    VAR NAME VALUE
+</Code>
+or if you want to be fancy you can index the value by string name; ex. variables[s] where s is the string value of something like
+<Code:JavaScript>
+    INPUT using A
+    VAR NAME is A
+</Code>
+The interpreter can read and write, even to a map (dictionary) if string indexing is not available.
 === The VM idea
-The idea is that we get around the limitations of JavaScript (or any modern game engine, or, single threaded environment) by creating a virtual machine that accepts commands, like a computer or cpu that pulls instructions and executes them in the context of some environment. This environment has defined inputs and outputs to the screen, the DOM, or for whatever use it requires. As long as one event can be processed in one 'cycle' then context doesn't matter and we can ignore context in terms of sharing a thread with the UI. We can subvert the UI thread to create events, and then process them within the context of our program, updating the up whenever we need to.
+The idea was that we would get around the limitations of JavaScript (or any modern game engine, or, single threaded environment) by creating a virtual machine that accepts commands, like a computer or cpu that pulls instructions and executes them in the context of some environment. This is what the original idea was, we would create an event after we processed the input in 'input mode' (such as SET_NAME). But then, it became obvious that the same system, taken a little further could also do variables, and even simulate BASIC (line numbers could be array indexes, for easy sorting and renumbering).
+This led to the realization that having two modes wasn't really necessary. There should only be one mode, and when input is needed an input flag could occur which would put characters into a string buffer OR which would trigger a line read from a cursor position, or, on the current line, or context, as contextually implied by the environment. For example a command line has different parameters than a 'What is your name?' prompt in Nethack, or a simulated getkey.
-Carried to an obsessive conclusion, we are essentially writing a CPU simulator which handles opcodes, and then writing assembly language programs using that, and projecting the input and output into the faux memory of this virtual CPU.
+Eventually it became obvious that the system was falling towards a CPU/System simulator. My mind jumped to 'emulator', even though that would be overkill, as a way to try and define an upper bound to what I would need to do.
-In practical terms, what this means is we can simulate string input by having command mode switch to a terminal and then back again to process one line of input.
+This topic became too large to fit inside the JavaScript Terminal or JavaScript Netwhack idea, so I will write about it somewhere else, maybe [[JavaScript Virtual Machine]].
 == Code Commentary
@@ Line 851: / Line 897: @@
 == Color.js
 Several new colors have been added. Standard greens and ambers based on phosphor wavelength values, as well as look-and-feel approximations of greens and ambers from an IBM 3270. Some look and feel ambers, and some phosphor and/or look and feel consensus opinions on the AppleII and AppleIIc have been added. In a v3, we may also decide to include more colors (such as for VIC-20, C64 and C128) and special fonts to simulate these terminals. For now the extra colors are there to demonstrate how to use the immediate command mode in Terminal (ex. by typing 'help').
+== Bugs
+There were a few bugs. One early bug from v1 is that we have to keep setting the font when we draw tthe character, or for some reason it doesn't seem to trigger and can corrupt the screen.
+Another bug is related to resizing the terminal. It may be better to simply regenerate the character array instead of creating a whole new terminal because a 'class' of bugs was introduced by not copying certain data properly and I had to keep going back and fixing it. There are probably still bugs remaining because of this, and the way to really fix them and also make the code simpler, is to merely regenerate the array in place. This will also give us the opportunity to change the font size on the fly, and so, it is slated for v3.
+There is a 'bug' in the system message that if the screen is too small it wraps around and then is overwritten by other parts of the system message. This is a 'deal with it' thing, because I haven't bothered to put any checks in because that would be game dependant. This is just intended to be a barebones system -- putting in checks for stuff like that is end user material.
+There was, actually however, a bug in that system I did fix, if it is called with negative cx it doesn't do anything. I fixed that (I think). Actually that is also barebones stuff. Don't call it with negative CX. You (the systems programmer) should know -- you have access to the width of the terminal. Use it.
+In that sense there aren't really any other serious bugs, it basicaly works as intended (I checked). If it's something I didn't check then you will be able to work around it in the game code.
 == Closing Thoughts
 This is an exciting platform to work with, once it is understood. To understand how to use this platform and how to extend it towards your game, I will discuss my plans for extending this code-base into JavaScript NetWhack. I will put this in a page [[JavaScript NetWhack]].