Joseph Ferano
9a820d86cd
The script is in tools/ rather than thrown away, because two lanes are
writing Flan in the old spelling right now and their files need the same
pass at merge.
It works on forms, not on text: a keyword becomes a dot only where it sits
in a field-label position inside a brace, so an enum member in value
position, a map key inside an EDN string and a type-position {K V} are all
left alone. :keys keeps its colon -- it names no field.
60 lines
2.8 KiB
Plaintext
60 lines
2.8 KiB
Plaintext
;;;; core-input-virtual-controls.flan's other half: no window, a scripted
|
|
;;;; pointer, hash where the player ended up.
|
|
;;;;
|
|
;;;; The same split sand.flan and sand-headless.flan already have, and it is
|
|
;;;; available here for the same reason: the interesting part of that example —
|
|
;;;; which D-pad button is under the pointer, and what a held button does to
|
|
;;;; the player — is arithmetic over numbers, so it runs with no window, no GL
|
|
;;;; context and no libraylib. The link follows what the program reaches:
|
|
;;;; nothing below calls into raylib, so no shim is compiled and no -lraylib is
|
|
;;;; passed, and the example's own drawing functions are never emitted — which
|
|
;;;; was checked with ldd on the built binary: libm and libc and nothing else.
|
|
;;;; The example's `main` is not exported, so the only main is this one.
|
|
;;;;
|
|
;;;; Unlike sand-headless there is no wasm32 case for it yet. Nothing here
|
|
;;;; should stop one, for exactly the reason above — but it has not been run,
|
|
;;;; so it is not claimed.
|
|
;;;;
|
|
;;;; It is the only one of the ten ported examples with a headless case, and
|
|
;;;; the honest reason is that it is the only one that earns it. The other nine
|
|
;;;; are input read straight into drawing calls: a test of them would assert
|
|
;;;; that raylib answers 0 for every input with no window open, which is also
|
|
;;;; what a binding with its arguments crossed would answer.
|
|
;;;;
|
|
;;;; What this DOES pin: that the four buttons are where the geometry says they
|
|
;;;; are, that the diamond hit test uses x and y the right way round, and that
|
|
;;;; the four directions move the player the four different ways. A crossed
|
|
;;;; axis anywhere in nearest-button or move-player changes the hash.
|
|
|
|
(import vc "../../examples/core-input-virtual-controls.flan")
|
|
(import rl "vendor:raylib")
|
|
|
|
;; A sixtieth of a second, fixed. The real program uses get-frame-time, which
|
|
;; is exactly the thing a headless run has no answer for.
|
|
(defconst dt f32 0.0166666)
|
|
|
|
;; A lawnmower sweep over the pad's corner of the screen, two pixels at a time.
|
|
;; It crosses all four buttons and the dead space between them, so every branch
|
|
;; of nearest-button is taken and button-none is taken most of all.
|
|
(defconst sweep-x0 20)
|
|
(defconst sweep-x1 180)
|
|
(defconst sweep-y0 280)
|
|
(defconst sweep-y1 420)
|
|
(defconst sweep-step 2)
|
|
|
|
(defn main [] i32
|
|
(vc/reset-player)
|
|
(let [y sweep-y0]
|
|
(while (<= y sweep-y1)
|
|
(let [x sweep-x0]
|
|
(while (<= x sweep-x1)
|
|
(let [p (rl/Vector2 {.x (f32 x) .y (f32 y)})]
|
|
(vc/move-player (vc/nearest-button p) dt))
|
|
(set x (+ x sweep-step))))
|
|
(set y (+ y sweep-step))))
|
|
;; write-stdout and i64->bytes are builtins (lib/check.ml), not prelude
|
|
;; functions, so this does not go through the printers.
|
|
(write-stdout (i64->bytes (i64 (vc/hash-player))))
|
|
(write-stdout (bytes "\n"))
|
|
0)
|