As I work on this game engine, slowly but surely I'm learning new programing strategies. Here's something I've learned in the last 24 hours: It is one thing to write a program; it is entirely different to write a program to emulation another programing language.
Let me further define the situation here. When you write a program, a compiler turns your code into machine language (or some sort of pseudo code anyway). When your program is running, there are a series of transistors that physically turn on and off electricity to components of your CPU, using the electrical impulses that comprise your program's binary digits machine code to direct that activity. The part of your CPU that gets activated begins to carry out activities by turning further transistors on and off , all in response to the pattern of electrical impulses you programed for it. One part of your CPU causes a word of data to be read from memory and placed into a register. Another part might take that word of memory and perform some sort of math function on it. Other parts of your CPU send signals out to your video card, and those signals further instruct that video card to read memory. Those signals cause the video card to generate a new signal to your monitor, allowing you to read this excessively verbose test.
The point is, all the processing happens at a physical level in the CPU; physical transistors being turned on and off by our inputs and the program's instructions. This all happens extremely quickly, and all in the background, so it is easy to forget what is happening at the lowest levels of our machines.
When your program supports scripting, you have to read in some sort of file, and the patterns of characters tells your program how to carry out certain pre-programmed tasks. If you want your script host to be able to pop up a message box for the user, you have to define a pattern of characters that your program can recognise, that direct it to do so. Your program spends a great deal of time analyzing the characters in this script file, and your program has to be careful how much time it devotes to doing this. If your program is a game engine, you will already be spending a great deal of time telling the video card where and how to display any number of graphics on the monitor. You don't want to take away from that time, or the game will start running slower.
To compare how quickly the physical CPU is at running a program to a piece of software analyzing one and emulating it on the fly, is very difficult. I would estimate the emulation to be many hundreds of times slower; perhaps even thousands of time slower.
Imagine you want your game to run at 60 frames per second. That means your program has 1/60th of second (or about 0.0166 seconds) to check the keyboard, mouse and controllers, figure out what that input means to the game, and take action on it, update all of the physics for all the objects in the game, then finally tell the video card where and how everything is supposed to look on the monitor. Online games also have to deal with incoming data from the server, updating the world objects accordingly, and prepare and send packets of data back to the server to let it know what input the game got from the user.
Computers are fast, but this can be a LOT of work to do in such a short amount of time. And, the game isn't the only thing the computer is doing at that moment in time. Your program doesn't get to run continuously when it is running. Instead, windows assigns "time slots" for your program to run in, called a quantum. A quantum is a unit-less measure of CPU time. For most desktop computers, the 3 quantum is going to equal about 10 milliseconds on a single processor system, or 15 milliseconds on a multi processor system. How many quantum your program gets for execution each time it is scheduled depends on a number of very complex factors, but can be anywhere from 3 to 12 quantum.
Once you start to realize that your program doesn't necessarily get time slices that line up with your desired 1/60th of a second, you notice there's a problem here. If your program spends its entire quantum of time running a script, you will miss your window of opportunity to display an updated frame. Too much of that, and your program will run very choppy. Your monitor's vertical refresh pulse can't wait around for your game to catch up, of the display will start to flicker, a subjectively even worse condition.
So, I'm going to work on these challenges as I design the script engine, and if I come up with anything clever, I'll be sure to post them.
No comments:
Post a Comment