3 ms·
Sort of ... but I think it's easier to do the disk access as usual, but move your real-time game code (updating graphics, taking care of input) to a timer inter
by actionfromafar 3y ago
Sort of ... but I think it's easier to do the disk access as usual, but move your real-time game code (updating graphics, taking care of input) to a timer interrupt.
Edit: then you effectively have your main loop doing IO and such, while your game loop is a co-routine in modern parlance. The game loop can write a global variable which the main code takes as a hint to start loading file data.
- rzzzt 3y agoThe timer interrupt could also do the loading: - maintain a, say, ring buffer :) for I/O commands (operation, file handle, offset, buffer address, callback address) - add requests to the buffer from the game loop - timer wakes up periodically, splits requests into palatable chunks, completes a portion of the requested work, when it reaches the end it either sets a flag on the request to signal its completion and/or jumps to its callback address - game loop can periodically check and empty the request buffer or set the requests to self-destruct on completion
- actionfromafar 3y agoYeah either way, my hunch was just I wouldn’t want to drop frames in the game, so it’s nice have a timer on the graphics.
- turol 3y agoThat does not really work since the only IO was the BIOS-provided one that was 1. synchronous and 2. really slow. If you tried to do that you'd just get insanely bad pauses.