flan/examples/core-input-multitouch.flan
Joseph Ferano 8e47356592 A field label is a dot now, and the colon is refused where one was
The delimiter is what disambiguates: (.x v) is a call and therefore an
access, {.x 1.0} is a brace form and therefore a construction. The colon
kept two jobs -- field label and enum member -- and this leaves it with
one, keys, which is what a map literal will want.

The old spelling is refused rather than quietly accepted, and the refusal
names the new one. Two accepted spellings is how two spellings become
permanent, and this repo rejects what it does not support and says why.

:keys keeps its colon. It names no field -- it is an instruction to the
compiler that happens to sit in the same brace -- so leaving it alone is
what lets the dot mean exactly one thing.

render.ml prints the dot too, or a struct the daemon shows would not be
Flan anyone could paste back.
2026-09-12 14:51:57 +07:00

71 lines
3.0 KiB
Plaintext

;;;; raylib [core] example - input multitouch
;;;;
;;;; examples/core/core_input_multitouch.c. No new bindings: the whole touch
;;;; surface was already there for sand.flan's read-out.
;;;;
;;;; The C keeps `Vector2 touchPositions[MAX_TOUCH_POINTS]`, and this is the
;;;; first example that needs a fixed array whose element type is a STRUCT
;;;; rather than a number. That works — `[10 rl/Vector2]` is ten Vector2s laid
;;;; out flat, no headers, and `(at touch-positions i)` is a place that can be
;;;; assigned a whole struct. Nothing in the repository used one before, so it
;;;; is worth saying that it does.
;;;;
;;;; It is a top-level `defvar` and not a local, which is NOT a stylistic
;;;; choice. A `let` binding takes no type annotation, so the only way to make
;;;; a fixed array inside a function is to initialise it from a literal with
;;;; every element written out — ten `(rl/Vector2 {.x 0.0 .y 0.0})`s here, and
;;;; thirty-two in the gestures testbed. A zeroed local array of a given type
;;;; cannot be spelled. Static storage is what the C's `= { 0 }` gets anyway.
;;;;
;;;; On a desktop with no touchscreen get-touch-point-count is 0 and this draws
;;;; nothing at all, which is correct and is also what the C does. The window
;;;; opening and the help text appearing is the whole of what can be checked
;;;; without hardware.
(import rl "vendor:raylib")
(defconst screen-width 800)
(defconst screen-height 450)
(defconst max-touch-points 10)
(defvar touch-positions [max-touch-points rl/Vector2])
(defn main []
(rl/init-window screen-width screen-height
"raylib [core] example - input multitouch")
(defer (rl/close-window))
(rl/set-target-fps 60)
(until (rl/window-should-close?)
;; Update
(let [count (min max-touch-points (rl/get-touch-point-count))]
(dotimes [i count]
(set (at touch-positions i) (rl/get-touch-position i)))
;; Draw
(rl/begin-drawing)
(rl/clear-background rl/raywhite)
(dotimes [i count]
(let [p (at touch-positions i)]
;; raylib reports (0,0) for a slot that is not being touched, so the
;; C filters on it and so does this. It means a real touch in the
;; very top-left corner is dropped; that is raylib's ambiguity, not
;; something the port introduced.
(when (and (> (.x p) 0.0) (> (.y p) 0.0))
(rl/draw-circle-v p 34.0 rl/orange)
;; The C's TextFormat("%d", i). This used to need examples/digits.flan
;; and a table of one-character strings; (string b) makes the
;; number a string with no instructions, so it is one draw-text and
;; this file imports nothing but raylib.
(rl/draw-text (string (i64->bytes (i64 i)))
(- (i32 (.x p)) 10) (- (i32 (.y p)) 70) 40
rl/black))))
(rl/draw-text "touch the screen at multiple locations to get multiple balls"
10 10 20 rl/darkgray)
(rl/end-drawing))))