Qbasicnews.com

Full Version: WINDOW vs non-WINDOW graphics. Speed penalty?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Since the WINDOW command seems to accept real numbers as input, I've always thought that it would make it slower to draw shapes and place sprites on screen, compared to a non-Windowed screen environment. But when I did a very simple (not very deep either) speed test, drawing circles with the two different coordinate systems, the results were inconclusive. So the question is: should I refrain from using the Window command, to speed-up my graphics, or isn't it worth the disadvantage of not being able to change coordinate system on the go?
From a dissasembly of the LINE routine, it appeared to me that the the QuickBasic graphical commands are designed to work with the "programmable coordinate system" that the WINDOW command provides regardless of whether or not you've actually used WINDOW to change anything. This actually stumped me for a while. First I found the code retrieving what appeared to be the screen resolution from two different memory locations, and later calculating the address of a pixel in screen memory is performed what seemed to be a very strange sequence of operation that involved division. I was baffled until I remember to the WINDOW command. My guess is that when the SCREEN command is used to change the screen mode, the effective coordinates of the screen are initialized to the resolution of the screen mode until you explicitly change them, but whether you do or not, the graphics code behaves the same way.
Interesting analysys, thanks.