* These parameters are only allowed in v7.0 (the default is used in prior versions of BASIC).

 

Bitmap graphics state management; enables or disables coordinate scaling.

 

When BASIC first starts, SCALE is not active.  So points (coordinates) given to the various bitmap graphic commands and statments will refer to physical screen pixels (assuming the point is on-screen).  Use the SCALE command to enable (or disable) the scaling feature.

 

The optional vWidth and vHeight set the logical (virtual) size of the bitmap screen. If these are omitted, they both default 1024.  These values have no effect when you turn scaling off.(set active to 0).  By using SCALE, a series of GRAPHIC commands can be used to render an image in different sizes.  For example, you could write a subroutine to draw a house "full screen" (with scaling off), and tweak it so it looks great.  The user of your program may never see this; when your program runs, it might then calculate a distance from this house, set an appropriate SCALE, and call that same rendering routine.  The result is different sized houses using the same code. 

 

Now scaling sounds kind of neat, and I guess it is, but there are two problems.  The first is you can only define the width and height -- the 0,0 origin is alway at the top-left of the screen.  And the scale must always be positive.  It would be much better if you could define all four ordinates (top, bottom, left, and right); this would allow the top-left corner to be something other than 0,0 and it would allow negative scales (i.e., reverse horizontal or vertical directions).

 

The second problem is the vWidth and vHeight may not be less than the physical size of the screen (in pixels).  This means you can use SCALE to "reduce" the size of draw commands (by using a big SCALE), but you can not "magnify" the size of the draw commands; at least not directly.  As mentioned with the house example above, you could start with a big SCALE and then use a smaller SCALE in order to effectively "magnify" the result.

 

Maybe the best use of SCALE is to adjust for the "pixel aspect ratio".  In other words, because the pixels of the TED and VIC-II chips are not square in either high-resolution or multi-color modes, CIRCLEs and BOXes will not look right, according to normal math formulas.  (For example, a BOX with equal length and width would be a square in the real world, but on a CBM they render as a rectangle due to the pixel aspect ratio.)  The right SCALE to use that compensates for the non-square pixels varies based on the video chip (TED/VIC-II) and the NTSC/PAL video standard.  That is, based on the physical screen size (interstingly, high-res / multi-color mode does not matter).  To make things worse, many TVs/Monitors these days will attempt to stretch the 4:3 picture of a TED/VIC to 16:9 size!  Assuming your display device is not stretching the image, SCALE 1, 400, 300 will give approximately square virtual pixels.  This assumes the active area (inside the borders) of the TED/VIC chip has a 4:3 aspect ratio; this is approximately true for both NTSC and PAL, but in reality PAL is bit wider (or you could say squashed vertically) while NTSC is a bit taller (or could say squashed horizontally).

 

Unfortunately the correction of pixel aspect ratio, while useful on TED (Plus/4) just as much as the VIC-II (C128), is normally not possible because BASIC v3.5 does not allow you to specify a custom scale.  However, a BASIC 7.0 ROM has been released for the Plus/4.  If you ever thought the built-in software was garbage, BASIC 7 sounds like a nice replacement ROM!

 

When SCALE is active, the points (coordinates) passed to commands need to be converted, which takes a bit of time.  Except for plotting simple points or characters (with the DRAW and CHAR commands), this CPU burden is very small compared to the time it takes to actually plot all the pixels on the screen.  So don't worry about the CPU/speed "cost" unless maybe you are drawing a bunch of random dots!  A bigger problem is routines that previously generated nice and smooth images will end up looking "pixelated" which is basically "quantization noise" due to the use of integer arithmatic in the graphics routines.  Note the graphics routines would be really slow (with or without scaling) on an 8-bit computer if they used floating-point calculations!

 

Any floating-point parameters will first be converted to integers (see INT).  If any value is out-of-range (see above) an ILLEGAL QUANTITY ERROR is generated.

 

This statement updates 1 to 3 secret variables.  The first one is a flag that indicates if scaling is enabled or not (i.e., the first parameter) and in v7.0 the two additional custom values (mangled values of vWidth and vHeight) are saved.  These are all secrets because BASIC provides no way to read their values.  They are, however, referenced internally by BASIC during execution of BOX, CIRCLE, DRAW, GSHAPE, LOCATE, PAINT, RDOT, and SSHAPE statments (and function).  In the case of GSHAPE and SSHAPE, the SCALE only affects the coordinate(s) to plot/save an image -- the actual size of the image is not scaled.

 

Examples:

SCALE 1 : REM scaling active, default 1024x1024 virtual coordinates
SCALE 1, 400,300 : REM scaling active, approximately square (virtual) pixels
SCALE 0 : REM scaling off, points refer to physical screen pixels

 

RDOT, RSPPOS, RWINDOW 

 

BOX, CIRCLE, DRAW, GSHAPE, LOCATE, MOVSPR, PAINT, SSHAPE