> it might have been the case, that there were not that many commands anyway, so that the linked list did not noticably slow things down.
Also, unlike the game code itself which has to finish running its work in time for every frame, it probably doesn’t matter if running a command from the Quake terminal takes a little bit extra time.
Would anyone notice or care about a difference in the amount of time it takes to run the /noclip command for example, in a O(n) vs O(1) lookup of the command in the probably short list of available commands? I don’t think so.
Speaking for myself, if I bring up the terminal in a game like quake to run a command, I’m probably standing stationary somewhere out of danger at the moment. And the amount of time I spend to tab open the terminal and type /noclip would be much greater than the amount that the game then takes to look for that command in its list of commands.
> Also, unlike the game code itself which has to finish running its work in time for every frame, it probably doesn’t matter if running a command from the Quake terminal takes a little bit extra time.
Except we did, because back then, the console command loop was part of the work done every frame - so your lookup still had to fit in the budget, or the player would see frames being skipped. Which, if memory serves me, happened as far as Quake 3.
Here's another important insight about how games were written back then: they were single-threaded. Rightfully or not, the cost of context switching was seen as too big, so everything was run in a single thread - maybe with an event loop (what kids these days call "async") thrown in for convenience, especially around UI. The games that did use threads, would use a small amount of them to offload some work that wasn't strictly frame-bound, or when outside main gameplay (e.g. in menu). I actually can't think of any game from that era, which would run multiple threads during main gameplay.
And sure, you can adapt the console with your linked list lookup to run on the event loop ("async"), so it would e.g. do a fixed number of search steps, then yield, and resume next frame. But the code for that would get much, much more complex than replacing a linked list with an array, even if you then also replaced linear scan with binary search.
So one other thing about games back then: things were much simpler, and skipping frames wasn't that big of a deal-breaker. Multiplayer wasn't so popular, there was nothing you could honestly call physics code - which would explode if you skipped frame without compensating, etc. And players were used to getting anything from 6 to 60 FPS, depending on hardware they owned. These days, a game console blocking main gameplay thread and causing frame skips, would be unthinkable.
Single threaded kind of makes sense for machines with single core CPUs. And multiplayer was usually limited because internet wasn’t that good typically being dialup.
Games required more cutting edge machines (maybe 2 years old) I remember getting a notebook with enough power (66mhz, 4 megs of ram) to place doom. Taking my machine to a friends and playing one on one death match over a serial cable.
But you were not typing a console command each frame didn't you? A spike of 0.X ms when you type a console command and hit enter won't be anything to worry about
Also, unlike the game code itself which has to finish running its work in time for every frame, it probably doesn’t matter if running a command from the Quake terminal takes a little bit extra time.
Would anyone notice or care about a difference in the amount of time it takes to run the /noclip command for example, in a O(n) vs O(1) lookup of the command in the probably short list of available commands? I don’t think so.
Speaking for myself, if I bring up the terminal in a game like quake to run a command, I’m probably standing stationary somewhere out of danger at the moment. And the amount of time I spend to tab open the terminal and type /noclip would be much greater than the amount that the game then takes to look for that command in its list of commands.