Files

Draw into the whole window, not its top-left 320x200

The graphics verbs documented a coordinate transform that did not exist. With
SCALE off a coordinate went straight to akgl_draw_* as a pixel address, so an
800x600 window drew a C128 listing into its corner and left the rest unused --
while the chapter said coordinates were 320x200 and stretching to fit was the
host's business.

akbasic_GraphicsBackend gains a size entry point, require_graphics() asks it
before every verb that draws so a resized window is honoured between two
statements, and 320x200 becomes the fallback for a backend that leaves it NULL.
It is the record's one optional member, so a host written against the old header
keeps the behaviour it had.

SCALE now maps onto the device, and RGR(1)/RGR(2) report the drawing surface so
a program can use a window whose size it did not choose. RGR(0) is BASIC 7.0's
own field, the GRAPHIC mode.

SCALE also mapped xmax onto the width rather than onto the last pixel, so
SCALE 1, 319, 199 followed by DRAW 1, 319, 199 drew nothing at all -- one pixel
past the surface. Fixed in the same line, because it is what makes "SCALE gives
a C128 listing the whole window" true rather than nearly true.

The akgl test renders against a 128x128 target, deliberately smaller than the
old constants: a SCALE still dividing by them misses it entirely rather than
landing somewhere plausible.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-01 07:35:20 -04:00

4.4 KiB

Raw Blame History

8. Sprites

Eight sprites, numbered 1 to 8, as on a C128. They need the SDL build.

A sprite here is a real object in the host's graphics library, registered alongside whatever the host's own game is drawing — so a game that embeds this interpreter can see and manipulate a script's sprites.

Giving a sprite a picture

SPRSAV does it, and it takes three kinds of source.

From an image file

10 SPRSAV "ship.png", 1

The most useful form, and not one a C128 has. The path is tried against the working directory first and then against the directory the running program was loaded from — so a .bas stored beside its artwork works wherever you launch it from. Anything the image library can decode will do.

A sprite loaded this way takes the image's own size. It is not forced to 24 by 21.

From a saved region

10 BOX 1, 0, 0, 24, 21
20 SSHAPE A$, 0, 0, 24, 21
30 SPRSAV A$, 1

Draw it with the graphics verbs, capture it, install it. The C128 documents SPRSAV's string as the SSHAPE data format at a fixed 24 by 21, so sharing the mechanism is faithful rather than a shortcut.

From data

10 DIM P#(63)
20 FOR I# = 0 TO 62
30   READ P#(I#)
40 NEXT I#
50 SPRSAV P#, 1
60 DATA 255, 129, 129, ...

63 bytes: three per row, twenty-one rows, most significant bit leftmost. This is the form a type-in listing uses.

It takes an integer array, not a string. A C128 puts the raw bytes in a string; a string here is NUL-terminated, so it cannot hold a zero byte and therefore cannot hold a sprite. DIM P#(63) is exactly the right size.

Writing a sprite back out — SPRSAV 1, A$ — is refused. That would be a disk operation.

Showing and moving

10 SPRSAV "ship.png", 1
20 SPRITE 1, 1, 3
30 MOVSPR 1, 100, 50

SPRITE n [,on] [,colour] [,priority] [,xexpand] [,yexpand] [,multicolour]. Only the number is required and an argument you leave out is left alone, so SPRITE 1, 1 turns sprite 1 on without disturbing its colour.

MOVSPR has four forms, and the punctuation is what tells them apart:

Form	What it does
`MOVSPR 1, 100, 50`	put it at (100, 50)
`MOVSPR 1, +10, -20`	move it by that much
`MOVSPR 1, 10 ; 90`	move it 10 pixels along bearing 90
`MOVSPR 1, 45 # 8`	set it moving along bearing 45 at speed 8

A bearing is degrees clockwise from straight up, so 0 is north and 90 is east. In the polar form the distance comes first and the angle second — the opposite order from the continuous form, which is a trap worth remembering.

The continuous form does not move anything on the statement itself. The sprite moves as the program runs, paced by the host's clock. Speed 0 stops it.

Coordinates are the same window pixels the drawing verbs use, not the VIC-II's raster coordinates — see Chapter 6, and RGR(1) and RGR(2) for how big the window is. SCALE does not apply to them: a sprite is positioned in device pixels whatever the drawing verbs are doing.

Collision

10 COLLISION 1, BUMPED
20 REM ... main loop ...
90 GOTO 20
100 LABEL BUMPED
110 PRINT "HIT: " + BUMP(1)
120 RETURN

COLLISION 1, target calls a subroutine when two sprites overlap. The handler is entered between lines and must end in RETURN, exactly like a GOSUB body. Omitting the target disarms it.

BUMP(1) returns a bitmask of which sprites have collided — bit 0 is sprite 1 — and reading it clears it, which is what makes "has anything hit me since I last looked" answerable.

Only type 1, sprite-to-sprite, is implemented. Types 2 and 3 are refused by name.

Collision is by bounding box, not by pixel: two sprites whose boxes overlap but whose artwork does not are reported as colliding.

Reading state back

Function	Gives
`RSPPOS(n, 0)`	x
`RSPPOS(n, 1)`	y
`RSPPOS(n, 2)`	speed
`RSPRITE(n, f)`	one of `SPRITE`'s settings, in `SPRITE`'s own argument order
`RSPCOLOR(1)` or `RSPCOLOR(2)`	one of the shared multicolour registers

These read the interpreter's own state rather than asking the device, so they work even with no device attached.

SPRDEF

Not implemented, and deliberately. It is an interactive full-screen sprite editor driven by single keystrokes, not something a program can call — and this interpreter does not own the screen it would take over. The three SPRSAV forms replace it.

4.4 KiB Raw Blame History