Multitasking

sounds very easy, if its just changing how you approach writing programs. Maybe harder if you are writing a tool that converts existing programs to be ran simultaneously. But if the idea in mind is a tool that scans a program and looks for problem scenarios that tell the coder "this needs to be cleaned up for multi-task environment" they can then do the necessary changes, then it might be easier. Or is it more like a runtime/OS? Would it be like a parent program running two child programs? Assuming a non multi-tasked program uses a lot of sprites, the parent program would probably handle storing sprite states, keep a count of how many maincnt frames the program has ran for. Would have to detect the child's main loop and make it a function, make sure the function is using globals instead of function locals. saving graphics state in an array might take a lot of memory because you can't save it I think without a save dialog box. its alot easier if the program knew and implemented functions or was written knowing that its sprites were "volatile" I think is the word. Implemented a "multitask" interface. I'm sure it would mirror modern os apis, minimize/maximize or lost focus, focused etc knowing that it not longer should affect the screen and should quickly perform its tasks. don't perform vsyncs, waits, don't block waiting for a keypress or cause dialog boxes. Asks the parent if there is enough memory to save its own graphics page, if the page will be destroyed etc. the parent program could also scan the programs public functions for commands that would violate the behavior of idle'd/slept program and throw an error before loading the program saying it doesn't obey the multi-task rules etc. Were you looking for a more interleaved execution where every program is guaranteed access every frame? I don't know how to do that with things that wait until a button press etc.. vsyncs might be the thing to replace with the mechanism that tells the parent "I'm done, goto the next child's needs" the bgmchk would have to be struck out when not focused. But what if people made games that didn't use music, and somebody made an SB music player that played music while you play a game in a different slot. the music player need access to the bgmchk function in that case. Alot of possibilites for a multi-task environment. using an editor, with your "pet-simulator" running in the background and makes an alert sound, and you get a scrolling marque across the bottom saying its hungry, and sb music playing in the background..granted I don't think there is a lot of demand for stuff like that..but why not.