Graphical Window Sprites

version 1 by Erik Temple

  • Home page
  • Beginning
  • Previous
  • Next

  • Section: Drawing Rules

    Graphical Window Sprites uses the Simple Graphical Window extension to provide basic control over the graphical window. Various parameters of the window can be set, including the size of one of its dimensions (either the width or the height, depending on whether the graphics window appears above, below, or to one side of the main window). See the documentation for Simple Graphical Window for more detail.

    Graphical Window Sprites, however, defines its own rules for drawing the images in the graphics window. The two rules defined in the extension are:

        the sprite-background scaled-centered display rule
        the sprite-background centered display rule

    The former scales the background image and sprites down to fit the current graphics window size and centers them both horizontally and vertically within the window. The latter centers them within the window but does not scale them; they are displayed using the pixel dimensions of the original files. The scaled-centered rule will not scale images to greater than their original size.

    We must specify the rule we wish to use in our source in order to draw our sprites to the screen. Usually this will be done in a "when play begins" rule:

        When play begins:
            now the currently shown picture is Figure of Background;
            now the current graphics drawing rule is the sprite-background centered display rule

    This tells Inform to draw both the background image (the currently shown picture) and sprites to the screen when the game begins. Simple Graphical Window will ensure that the screen is also redrawn whenever the window is resized or otherwise changed by the player.

    This is probably fine if we want the screen to remain the same throughout the game, but if we want to update the graphical window during play, we will need to tell Inform precisely when to do this. Perhaps the easiest way is with an every turn rule, but depending on our particular application, this may mean that the window is often redrawn needlessly, and we may prefer to tailor things a bit more. If our sprites are updated whenever the player enters a new room, for example, we might attach our updating rules to the looking command, since this is invoked automatically whenever the player moves from room to room:

        Carry out looking (this is the sprite-window update rule):
            Follow the current graphics drawing rule.

    If we have elsewhere provided rules for marking our sprites display-active and display-inactive, this will update them each time the PC moves. Here is a rule that both marks sprites for display and displays them; it ensures that the sprite associated with a given room is drawn when the player moves into the room:

        A room has a sprite called the room-sprite....

        Carry out looking (this is the sprite update rule):
            If the room-sprite of the location is display-inactive:
                change the room-sprite of the location to display-active;
            Follow the current graphics drawing rule.

    If we only wish to use the special sprite mechanisms for part of our game, that is possible too. We merely need to change the current graphics drawing rule to one of those defined by Simple Graphical Window (or one we write ourselves), and we can use the window as described in the Simple Graphical Window documentation. To draw with sprites again, we simply change the current graphics drawing rule back to one of the Graphical Window Sprites rules.

    Authors will find it easy to write their own sprite display rules, should they need them. This will not be covered in detail here, but using the extension's "draw the background," "draw active sprites," and "draw sprite X at coordinates x and y with dimensions m and n" phrases, we should be able to do just about anything we like without dropping into I6 code, since all of the variables we need are exposed at the I7 level.

    Finally, it should be noted that there are inherent inaccuracies in the scaling process, which may cause sprites to appear one or even two pixels out of place when scaled down. If a high degree of precision is needed, we should avoid scaling by using the sprite-background centered display rule rather than the sprite-background scaled-centered display rule. Alternatively, if appropriate, we can make sprites that will displayed directly adjacent to one another overlap slightly; this overlap will prevent unsightly "seams" caused by misalignment in the composite image. The image files used for the rooms in the "Castle of Sprites" example below use this approach, with 2 to 3 pixels of overlap between tiles.