flan/examples/core-input-virtual-controls.fln

186 lines
8.6 KiB
Plaintext

;;;; raylib [core] example - input virtual controls
;;;;
;;;; examples/core/core_input_virtual_controls.c. No new bindings.
;;;;
;;;; Split the way sand.fln is split: everything above the second banner is
;;;; arithmetic with no raylib calls in it, so test/programs/virtual-controls-
;;;; headless.flan can import this file as a package, drive the pointer over a
;;;; scripted path and hash where the player ended up. That is the only one of
;;;; the ten examples with a headless half, and it has one because it is the
;;;; only one whose interesting part — which D-pad button is under the pointer,
;;;; and what that does to the player — is a function of numbers rather than of
;;;; a frame buffer. The link follows what the program reaches, so the headless
;;;; driver pulls in neither a window nor libraylib.
;;;;
;;;; Two language notes, both visible below.
;;;;
;;;; **No `break`.** The C's nearest-button search is
;;;;
;;;; for (i = 0; i < BUTTON_MAX; i++) { if (...) { pressedButton = i; break; } }
;;;;
;;;; and `break()` is refused: "break is not implemented yet (see the build
;;;; sequence in plan.org)". `return` from the function works and is what this
;;;; uses — which is why the search is its own `defn` and not written inline
;;;; the way the C has it. That is not a loss: the function is the thing the
;;;; headless case wants to call anyway. Where a loop genuinely cannot be a
;;;; function, the shape left is a flag and a compound loop condition.
;;;;
;;;; **No `fabsf`.** The prelude has sqrt-f32 and sign-f32 but no absolute
;;;; value for floats, and the comment there says why for integers.
;;;; `max(v, 0.0 - v)` is it, and unlike the integer case it has no edge: there
;;;; is no float whose negation is itself except -0.0, whose absolute value is
;;;; 0.0 either way.
;;;;
;;;; The button geometry is `const` arrays of struct literals. That works —
;;;; and it is the only way a fixed array can be made inside anything but a
;;;; top-level `once`, since a `let` binding takes no type annotation.
import rl "vendor:raylib"
const screen-width = 800
const screen-height = 450
;; The C's PadButton enum. -1 is BUTTON_NONE and the four directions are 0..3,
;; in the order the arrays below are written. An `enum` would not help: the
;; value is used as an index and an enum does not convert to an integer
;; ("i32 converts a number, found ..."), so it would have to be turned back
;; into one at every use.
const button-none = -1
const button-up = 0
const button-left = 1
const button-right = 2
const button-down = 3
const button-max = 4
const button-radius: f32 = 30.0
;; padPosition is {100, 350} and the buttons sit a radius and a half away from
;; it on each axis. The C computes these at run time from padPosition; they are
;; written out here because a const is compile-time and the numbers are.
const button-positions: [button-max rl/Vector2] = [rl/Vector2{.x 100.0 .y 305.0} ; up
; left
; right
; down
rl/Vector2{.x 55.0 .y 350.0}
rl/Vector2{.x 145.0 .y 350.0}
rl/Vector2{.x 100.0 .y 395.0}]
const player-speed: f32 = 75.0
;;;; ── The part with no raylib in it ──────────────────────────────────
once player: rl/Vector2
fn reset-player() -> ()
player = rl/Vector2{.x f32(screen-width) / 2.0, .y f32(screen-height) / 2.0}
fn abs-f32(v: f32) -> f32 = max(v, 0.0 - v)
;; The C's search, with `return` where it had `break`. Manhattan distance and
;; not Euclidean — the C adds the two axis distances and compares against the
;; radius — so the hit area is a diamond, which is deliberate: it makes the
;; four buttons tile without overlapping.
fn nearest-button(pos: rl/Vector2) -> i32
for i in range(button-max)
let b = button-positions[i]
dist-x = abs-f32(b.x - pos.x)
dist-y = abs-f32(b.y - pos.y)
if dist-x + dist-y < button-radius
return i
button-none
;; The C's switch on the pressed button. Nothing moves for button-none, which
;; is the `default: break`.
fn move-player(button: i32, dt: f32) -> ()
let step = player-speed * dt
if button == button-up
player.y -= step
elif button == button-left
player.x -= step
elif button == button-right
player.x += step
elif button == button-down
player.y += step
else
()
;; FNV-1a over the player's two floats, so the headless driver has one number
;; to compare. The floats are read through their bit patterns rather than
;; rounded to integers: rounding would hide exactly the kind of drift — a
;; crossed x and y, a step applied twice — the case exists to catch.
const fnv-offset: u64 = 0xcbf29ce484222325
const fnv-prime: u64 = 1099511628211
fn hash-f32(h: u64, v: f32) -> u64
;; No float-to-bits cast in the language, so the value is scaled and
;; truncated instead. 1024 keeps three decimal places of a screen
;; coordinate, which is finer than any real difference between two correct
;; runs and coarser than the last bit of an f32 — so this is reproducible
;; across targets where a raw bit pattern would depend on the FPU.
let n = i64(v * 1024.0)
g = h
for b in range(8)
g = g ^^ u64(n >> i64(b * 8) && 255)
g *= fnv-prime
g
fn hash-player() -> u64 = hash-f32(hash-f32(fnv-offset, player.x), player.y)
;;;; ── The raylib front-end ───────────────────────────────────────────
;; The arrowheads, one triangle of three points per button, in the winding
;; raylib wants — counter-clockwise, or it culls them and draws nothing. A
;; [4 [3 rl/Vector2]]: a fixed array of fixed arrays of a struct, which is the
;; deepest shape any of these ten examples asks for and which works.
const arrow-tris: [button-max [3 rl/Vector2]] = [[rl/Vector2{.x 100.0 .y 293.0} rl/Vector2{.x 91.0 .y 314.0} rl/Vector2{.x 109.0 .y 314.0}]
[rl/Vector2{.x 64.0 .y 341.0} rl/Vector2{.x 43.0 .y 350.0} rl/Vector2{.x 64.0 .y 359.0}]
[rl/Vector2{.x 157.0 .y 350.0} rl/Vector2{.x 136.0 .y 341.0} rl/Vector2{.x 136.0 .y 359.0}]
[rl/Vector2{.x 91.0 .y 386.0} rl/Vector2{.x 100.0 .y 407.0} rl/Vector2{.x 109.0 .y 386.0}]]
const label-colors: [button-max rl/Color] = [rl/Color{.r 253 .g 249 .b 0 .a 255} ; yellow, up
; blue, left
; red, right
; green, down
rl/Color{.r 0 .g 121 .b 241 .a 255}
rl/Color{.r 230 .g 41 .b 55 .a 255}
rl/Color{.r 0 .g 228 .b 48 .a 255}]
fn main() -> ()
rl/init-window(screen-width, screen-height,
"raylib [core] example - input virtual controls")
defer rl/close-window()
reset-player()
rl/set-target-fps(60)
until rl/window-should-close()
;; Update. Touch first, mouse as the desktop stand-in — and on the desktop
;; the left button has to be held, or the player would follow the cursor
;; wherever it went.
let touching = rl/get-touch-point-count() > 0
let input =
if touching then rl/get-touch-position(0) else rl/get-mouse-position()
let pressed =
if touching or rl/is-mouse-button-down(:mouse-left)
nearest-button(input)
else
button-none
move-player(pressed, rl/get-frame-time())
;; Draw
rl/with-drawing:
rl/clear-background(rl/raywhite)
rl/draw-circle-v(player, 50.0, rl/maroon)
for i in range(button-max)
rl/draw-circle-v(button-positions[i], button-radius,
if i == pressed then rl/darkgray else rl/black)
let t = arrow-tris[i]
rl/draw-triangle(t[0], t[1], t[2], label-colors[i])
rl/draw-text("move the player with D-Pad buttons", 10, 10, 20,
rl/darkgray)
;; Not in the C: which button the search picked, as a number, so the
;; headless case and the window agree about the same thing.
rl/draw-text("button: ", 10, 34, 20, rl/lightgray)
rl/draw-text(str(i64->bytes(i64(pressed))),
10 + rl/measure-text("button: ", 20), 34, 20, rl/lightgray)
;; The number drawn this frame was formatted into the temp allocator;
;; this hands that memory back once the frame is drawn.
free-temp()