The platform gave these keys no code at all, so a game's rebinding screen could not take
one and nothing said why. Windows asked the active layout what they type and got nothing
(w_vk_char answers 0 for a key with no character); macOS let them fall through to
charactersIgnoringModifiers, which reports NSF1FunctionKey and its neighbours at 0xF704
and up - outside the 256-bit held set either way.
w_keyval and ev_keyval now name them, with the same codes on both: 132-143 F1-F12,
144-149 Home / End / PageUp / PageDown / Insert / Delete, 150 Caps Lock, 152-161 the
numpad digits, 162-166 its * + - . and /. The numpad's Enter is Enter.
Key.F1, Key.Home, Key.Numpad0 and the rest fold at compile time, and Input.key_label
names them without asking the layout - a key that types nothing is called the same thing
on every layout.
examples/library/input_typeless_keys.ludic covers the codes, the names, the held set and
the press edge; 150 passed in ludic-dev test, 33 in selfhost-test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The runtime opens a game's window before main, titled with the program's name, and
gl_open attached to it without passing its title on (render3d's gvk_open called win_open,
which returns early on Windows and opened a second window on macOS). win_set_title in
cocoa.ll / win32.ll (setTitle: / SetWindowTextW, UTF-8 -> UTF-16; a no-op without a window,
stubbed headless) retitles it from gl_open, and win_open on an open window retitles it on
both platforms.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Process.spawn/poll/kill/free - non-blocking child processes with no shell: posix_spawn on
macOS (process.ll), CreateProcessW with MSVC-quoted arguments and no console window on
Windows (process_win.ll), linked only when a program uses Process.*.
Http.save_to streams a response body into a file (NSURLSession with a run-time delegate
class on macOS, the WinHTTP read loop on Windows); Http.received / Http.expected report
progress while it is pending. Freeing a pending request cancels it and parks the slot
until the worker has finished.
App.window_hide / App.window_show take the game's window off the screen and back without
closing it; the run goes on while hidden. Docs, examples, tests and a changeset.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Windows runtime keyed the held set by the character MapVirtualKeyA gave a
virtual key, so a game's WASD belonged to whatever the active layout put there,
and with an input method on every letter arrived as VK_PROCESSKEY. The typing
block is now read from the scancode (the arrows, numpad and F-keys still by
virtual key); macOS reads keyCode the same way. Input.key_label(key) names a key
in the player's own layout (Windows) or as its US character elsewhere.
Verified on Windows with SendInput into a live window: VK_Z carrying W's scancode
holds 'w', VK_PROCESSKEY carrying A's holds 'a', Caps Lock changes nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
win_native_window / win_native_instance hand a Vulkan swapchain what it is created on: the
HWND and module instance on Windows (VkWin32SurfaceCreateInfoKHR), the game's view on macOS.
Headless builds define both as null (weak on macOS, so a windowed link keeps cocoa.ll's), so
code that asks for them links everywhere and simply finds no window.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
http_win.ll implements http.ll's hs_* contract over WinHTTP: the request is a
record built on the game thread, the whole exchange runs on a worker thread,
TLS uses the system's certificate checks, and headers are answered from the
kept request handle. ludicc links it with winhttp instead of refusing Http.* on
Windows.
win32.ll decodes the splash and App.set_icon images with WIC (ole32): the
splash is a topmost borderless window at the artwork's size in points times the
display scale, composited over its background colour; the icon becomes an
HICON set on the window now or when win_open makes one.
Verified on the PC: examples/library/http.ludic prints its expected output, a
real GET to https://git.workshopsoft.io/ returns 200 with its body and
Content-Type, and the bundled Maroon Lake shows its splash centred at launch and
its icon in the title bar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A game asking for 960 x 540 got 960 x 540 pixels - a quarter of a 4K panel.
w_fit_scale turns the display's DPI into a whole-number scale (96 -> 1, 168 and
192 -> 2), brought down until the window fits; win_open and win_gl_resize size
the client area with it, win_gl_scale reports it the way cocoa.ll reports the
backing scale, and the mouse still arrives in the game's own units.
Verified on a 3840x2160 panel at 175%: windowed gl_triangle's 640x360 window
draws a 1280x720 frame.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
win32.ll implements cocoa.ll's contracts over user32 and xinput: the message
pump, the held-key set and frame key in Ludic codes, the mouse with raw input
for cursor mode 2, clip-based cursor modes released on focus loss, XInput pads,
and the software framebuffer present. win32_gl.ll puts the WGL 4.1 core context
on that window (vsync, borderless full screen); gl_win.ll's context code is now
lgl_wgl_core, shared with the headless hidden window, whose win_gl_* stubs move
to gl_win_nowin.ll. audio_win.ll links Audio.* silently for now.
Verified: macOS fixpoint, ludic-dev test 135/135, selfhost-test 32/32; on the
PC gl_triangle renders identically headless and in a real window, and Maroon
Lake builds windowed and runs a playtest to frame 240 in the desktop session.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
