Showing changes from revision #4 to #5:
Added | Removed | Changed
Entry | |
---|---|
R0 | Screen mode, or -1 for current |
R1 | Variable number |
Exit | |
---|---|
R0 | Preserved |
R1 | Preserved |
R2 | Value of variable |
C flag is set if variable or mode were invalid |
The purpose of this call is to read information about a particular screen mode without having to change into that mode.
The screen mode passed via R0 can be a mode number, a pointer to a Mode Selector Block, or a Sprite Mode Word.
This call does not check whether the video hardware can support the specified mode. For example, on a machine that only supports colour depths of 8bpp or greater, it is still possible to query the details of 1bpp modes, whether that’s via a mode number, mode selector block, or sprite mode word. This is necessary in order for sprites to work correctly. To check whether a mode is supported by the video hardware, use OS_CheckModeValid.
Because this call does not check the capabilities of the video hardware, the information returned isn’t always an accurate reflection of the mode variable values that will be used once the mode has been selected. For example, the LineLength and ScreenSize mode variables may be inaccurate if the video driver has restrictions on the framebuffer row stride. Or if a numbered mode is requested which can’t be directly supported by the hardware, a substitute mode will typically be used instead (e.g. the 256-colour mode 28 may be used instead of the 16-colour mode 27) – OS_CheckModeValid will indicate that this substitution will take place, but OS_ReadModeVariable will not.
For these reasons, it’s also important to make sure that when you’re interested in the details for the current mode, you either specify -1 as the mode number or you use another API such as OS_ReadVduVariables. Manually specifying the current mode number or selector block may result in inaccurate results.