The program itself doesn't do anything useful, it just displays the sprite in three different items, and in a canvas:
You should now resize the window to make it bigger/smaller. You will see that the sprite in the menu bar doesn't change size at all. This is because the menu itself doesn't change size.
The sprite in the second item will adjust itself so that it fills the item as much as possible, whilst still keeping correct proportions. This is the sprite that is drawn using the "LOOSE_SPRITE" tag with a normal ProWesS loose_item type. This makes sure that the sprite is drawn with correct proportions.
The third sprite just fills in its item as much as possible. Thus, it gets deformed when the x and y ratios aren't quite correct...
The sprite in the canvas behaves just like the second sprite. This is because it was drawn using the PWsprite command, which also makes sure that the sprite remains well-proportioned (like me). Please note that I could have used for this canvas the same way of drawing the sprite as for the third item...
You now have the ways to draw sprites in items, or any gstate you want (such as that of the canvas). The big disadvantage of sprites is that "pixels" get bigger when the sprite must be drawn bigger. However, this is not so much of a disadvantage for sprites that are contained in menu items. As we have seen, the sprite in the menu bar doesn't change, since the menu bar doesn't change size. Normally, loose items shouldn't change size either, even if in this example I've used an item that does (it's a case of do what I say, don't do as I do...). By the way, to make sure that items don't change size when the user resizes the window, include them in a direction item, for which you set the scale factor to 0. (You can see an example of that in the Procon program). I presume that this is what happens for the title bar, anyway (in the y direction).
As you can see, the sprite is built using the MKSPRT keyword.
last edited 1996 Nov 18 (wl)