With the advent of video drivers which may extend the SpriteV operations in order to provide acceleration it is necessary to be aware of the order of vector registration. Ensuring the ordering of vector claimants ensures that the system can be modularly extended, and restarted.
The SpriteExtend module has been updated to issue a number of service calls in order to initialise extensions to the Sprite vector after it has claimed the vector itself. This allows those claimants to process the calls before SpriteExtend itself performs the usual software operations. Three classes of extensions are expected and are provided for :
Type 0 - software vector extensions
These are extensions, similar to SpriteExtend, which provide core software implementations of new vector calls. For example, should there be a sprite operation to render a sprite to a draw path, this would be where the implementation would register its vector.
Type 1 - accelerated vector extensions
These are extensions which accelerate existing operations. Hardware video drivers would fall in to this category, allowing them to accelerate the existing operations when rendering to their display device.
Type 2 - monitor, or vector augmentation
These are handlers which either monitor the calls passed through the vector for diagnostic purposes, or which modify the vector parameters in order to provide some different implementation. It is not expected that there be many handlers at this level.
R0 = registrant type : 0 = software vector extensions 1 = accelerated vector extensions 2 = monitor or vector augmentation Others reserved R1 = &E1 (service number)
R0, R1 preserved (must not be claimed)
This service is issued by SpriteExtend after it claims SpriteV in order that other clients may register themselves in the correct order. It will be issued 3 times, once for each of the registrant types, in ascending order. It must not be claimed.
This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation.
HTML document version 1.03 3rd November 2015