Game design: separating game logic from display.

Hello, All I’m writing some blanks, potentially for a toy, so I’m thinking how It would be advisable to do this: Hang all the logic (keyboard polling, primitive AI, game physics) on interruptions, and the main output to the screen and copying information between memory banks implement in the main time. What will this give? independence of the game progress from the processor speed and, with thoughtful implementation, so to speak, of an fps system. I have little experience in game development, so your opinions are needed. What can you do say about this? What could be the disadvantages of such a system? the output goes to both screens, not through the stack, but using the table first offset bytes.

Hello, moroz1999 IG#6/code/Game loop

Hello, moroz1999 mor> I have little experience in game development, so your opinions are needed. What mor> can you say about this? what could be the disadvantages of this mor> systems? It is very difficult to evaluate this scheme, because it all depends on what kind of graphics, is it necessary to change the border synchronously with the screen... In general, a lot factors that may affect the structure of the code. I always try my best works with the image only on interrupts, although this forces constantly look for ways out of dead ends, but ultimately leads to optimal code, or close to ideal. And outside of the interruption I do all sorts of depackengs and decranchengs However, I once had a keyboard with a 1 meter long cable, I was very loved to put his legs out and program in a waddle. And the cable length had a big impact to check the keyboard bounce. That's why I have one very wonderful one ONE-FRAME text editor with unusual key polling. But not everything in this world you'll take it into account. Although this is me with my ASMA view of the “WORLD”!!!

Hello Robus Of course, it is necessary to separate game logic from screen output - but this is not necessary to do so cruelly is on interruptions, but this is not. as if it were clearer explain your point... Well, for example, here is our old game moorhuhn; //; on interruptions, polling keyboards, mice and playing music // display the cursor (each frame in a new place =) // most of the time processing data from controls (the frame is built and displayed in 2 frames // the following procedures: // movement of roosters (who, where, when, how) // shot processing (if there was, then what happened - did we kill the rooster?, subtract bullet?, calculation of "combo" // shot control // output to screen the last procedure processes the queue of sprites where the coordinates are indicated sprites and animation numbers. it absolutely (well, theoretically =) does not depend on remaining blocks, and again theoretically it can be changed at any time and/or rewrite...