Conflicts:
- render_objects.c: upstream's first-person legs and our VR body share one
node_matrices (ours no longer shadowed it); upstream's legs never in VR
(first_person_legs_wanted: set back behind a flat view's eye, they would
stand behind the player; the VR body is vr.body "full").
- AndroidManifest.xml: upstream's ':game' process left out (the Steam
Frame's Lepton waits for the app's process to end; the headsets have no
Java heap over the Xbox window); HaloApplication kept, idle without it.
- xinput_sdl.c: the touch controls and the web port's, never in VR; the
controllers' rumble in VR before the phone's.
- d3d8_gl.c: multiview's uniforms and upstream's blend constant, both.
- build.yml: Android only; upstream's web and pages jobs off.
- README.md: ours; upstream's in docs/OPENCE_README.md.
- menu_tags.c: our VR pause-list fit dropped: upstream now spaces the rows
30 apart and moves the button hints below them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Video Setup > FOV and Viewmodels > Shield Color: DEFAULT (the shield's own)
or one of the 18 multiplayer armor colors (player_profile.c's table: white,
black, red, blue, gray, yellow, green, pink, purple, cyan, cobalt, orange,
teal, sage, brown, tan, maroon, salmon), whatever the armor's color.
No new assets: the shield's own plasma shader is drawn, its perpendicular
and parallel colors replaced by the chosen color at their own brightness
(their brightest channel), so its noise, animation and intensity are the
shader's. A local player's unit is drawn with a copy of its change colors as
the modifier's colors (render_object_list); rasterizer_plasma_energy_draw
knows that copy again and replaces the shader's colors only for it. Plasma is
added to what is behind it, so black is drawn as a faint grey.
Only this machine's drawing of its own players' shields changes: others see
your shield as their own settings draw it, and nothing sent between machines
changes. Checked by compiling the changed units.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015jtk9vPUKbWd48oBMzXuzd
Video Setup > FOV and Viewmodels > Legs, off by default. In first person the
player's own body, which the game animates as everyone else sees it but does
not draw for its own player, is drawn from the waist down: looking down,
your legs walk, run, strafe and crouch as the body's animation moves them.
How it is drawn (port/linux/game/first_person_legs.c):
- A copy of the body's pose as drawn: everything but the hips and legs (by
node name: pelvis, thigh, calf, foot, toe) folded into a lid over the
waist, the root kept.
- The body set back behind the eye, each frame, as far as keeps the waist's
open rim beyond the bottom plane of the view (the way Halo 2's fp_body
keeps its open top out of sight): looking ahead, 4 cm; straight down at
105 degrees, about 67 cm. The legs are seen as they swing forward.
- Drawn with the world's camera, so it keeps its place and size at any FOV;
not in mirrors, not in the shadow pass, without what it carries.
The waist's rim is found from the model's own triangles: object_mesh.c reads
an object's drawn mesh (its most detailed geometry, in the permutations it
shows) from the vertex and index buffers the game draws it from, as
powerup_render_bounds.c reads them; its cache is forgotten on a new map
(objects_initialize_for_new_map).
Only the drawing changes: the body, its hit boxes, markers, the camera and
everything sent between machines are the game's. Checked by compiling the
changed units; the fold and set-back were checked against a capture of the
cyborg's mesh and pose and played on Windows.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015jtk9vPUKbWd48oBMzXuzd
The player's own biped is drawn in first person among the world's objects
(it sorts against the world by depth; the first-person weapon and arms,
drawn first into the stencil, stay over it), posed from a copy of its node
matrices once a frame (port/linux/game/vr_body.c): turned to the torso's
heading, the neck below and behind the eyes as the head turns about it, the
hips down with the physical crouch and part of the way with a lean, the
spine upright to the neck, the feet planted while standing and stepping
after the body as it turns, the knees bent by the arms' two-bone IK. The
head and the third-person arms are shrunk to nothing, the weapon and what
the biped carries left out; the first-person arms hang from the body's
shoulders (mirrored with the weapon left-handed). A passenger in an open
vehicle sits as the seat's animation has it; at a wheel or a gun the body
is drawn as before, in a closed seat none. Nothing of the game's own pose,
hit boxes or network messages changes.
The neck pivot, the planted feet and the leg's clamped reach follow
HaloCE-Quest-VR (CC0), rebuilt for this port's skeleton and caches.
vr.body gets "full" (VR options, Body: "Full body"); "arms" stays the
default. vr.log_performance reports the body's pose. debug.vr_body shows
the body flat (the emulator): from the eyes, looking down, or from the
front, side or back, the head turning, crouching or leaning on its own.
Checked in the emulator: the cyborg's 19 nodes found, the body posed
standing, crouched, leaning and turning (feet stepping), 0.006 ms a pose;
two-minute bot games on Blood Gulch with it on and off, no errors.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
248 OpenCE commits (network version 25): touch controls and touch menus for
phones, single-player in-game Settings, opt-in FOV/viewmodel settings, voice
chat and votes to kick, lens flare culling, memory leak fixes (render
targets, gamepads, the Android audio stream), profiling builds, the
HALO_ANDROID split into HALO_ARM64_GUEST / HALO_GLES / HALO_ANDROID.
Conflicts and how they were resolved:
- README.md: ours kept whole. Upstream's README changes (portable build,
profiling builds) went into docs/OPENCE_README.md: upstream's new text
with our header note, links rewritten to ../ and our "made from your own
copy" wording.
- port/android/README.md: both merged; upstream's touch, WSL and save
notes taken, with our application id in every adb path; our VR section,
signing.properties and wording kept; the stale "How it works" list
dropped as upstream dropped it.
- Launcher icons (mipmap-*/ic_launcher_foreground.png, art/android-icon.png):
ours (the Ringfall art). Upstream's helmet monochrome layers,
drawable/ic_launcher_background.xml and its ic_launcher.xml were left out;
our ic_launcher.xml, values/ic_launcher_background.xml and
tools/android_icon.py stay. (port/assets/icon and tools/app_icon.py come
in for the desktop builds' window icon only; do not run app_icon.py, it
would write the helmet into the Android resources.)
- port/android/host/host_main.c: both config helpers kept, and upstream's
emulator write tracking (native_bridge_active); upstream's display width
block dropped in favour of ours (640 in VR) and its display density for
the touch controls moved into our flat (non-VR) branch.
- port/linux/game/menu_functions.c: platform_text_field(typing, password)
from upstream; the VR keyboard launch for text fields kept after it.
- port/linux/game/network_distributed.c: upstream's profile_scope wrappers,
with network_vr_tick and bots_tick kept in their places.
- port/linux/src/dsound_sdl.c: both (our debug.audio_log, upstream's
audio.output_device).
- port/linux/src/port_config.c: our temp-and-rename config write kept,
under upstream's HALO_ARM64_GUEST (it is guest file I/O).
- port/linux/src/sdl_platform.c/.h: upstream's (Android menu pointer from
the touchscreen, Steam keyboard, scoreboard pointer); our quit marker for
the Steam Frame launcher, clipboard_seen and VR frame hooks kept. Our
flat-mouse menu pointer (an emulator aid) is replaced by upstream's touch
pointer, which also drives the menus on the emulator.
- port/linux/src/d3d8_gl.c: halo_ui_pointer_update is upstream's, with the
VR controller ray taking over while VR is active (the touchscreen then
is not the pointer); our persistent-buffer writes kept for stream and
index uploads, now writing upstream's exact length and under HALO_GLES
like the code around them (stream_reserve, index_upload, mirror_refresh
too); multiview uniforms stay under HALO_ANDROID, the counter binding
under HALO_GLES. Visibility counters: ours kept (the snapshot ring with
multiview views, host_gl_counters_snapshot) over upstream's per-frame
glCopyBufferSubData into counter_snapshots: ours reads finished frames
without stalling and counts both eyes' samples once; upstream's
desktop query batches come in unchanged.
- port/linux/src/xinput_sdl.c: both (VR controllers and touch controls).
In VR the touch controls neither show nor act (touch_input_gamepad,
touch_input_controls, touch move/look skipped); rumble goes to the
controllers in VR, to the phone otherwise.
- source/interface/first_person_weapons.c: both (VR scope pass check and
display.viewmodel_visible).
- source/interface/ui_widget.c: upstream's reworked menu targets taken
(ui_mouse_fit_button_targets, merged rows, widened values), which do
what our icon_x0 key picking and the 12-unit value arrows did; our VR
label distance (25) kept, and a VR ray counts as a coarse pointer, so it
gets the taller legend areas and the widened values (not the merged
rows: a row's label still presses A). Our join code and VR options
panels kept; their early return now forgets the frame's targets too.
The on-screen keyboard: upstream's virtual_keyboard_click for taps and
the mouse, ours (hover highlights the key) for the VR ray only.
- source/main/main.c: both (VR phases around upstream's profile scopes).
VR guards for new upstream features:
- view_fov.c: display.fov, display.viewmodel_fov and
display.viewmodel_visible do nothing while VR is active (the headset
gives each eye's frustum; the weapon is in the hand).
- Touch controls: off in VR (xinput_sdl.c), the menus' touch pointer too
(d3d8_gl.c); the overlay stays hidden as the game never reports a scene.
- Lens flare culling (744040c8, b1a71709) uses global_window_parameters'
frustum, which in VR is each eye's (per-eye passes) or the union frustum
of the multiview centre camera: no change needed.
- In-game Settings: VR options still open with Y on the main and pause
menus (checked flat with debug.vr_options).
- The back button change (enableOnBackInvokedCallback=false) keeps the
legacy KEYCODE_BACK path, which targetSdk 35 already had: no change on
Quest or Frame.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
render_fov.c, viewmodel_fov.c and viewmodel_visibility.c are one unit,
port/linux/game/view_fov.c, with a header comment as the others have, real
for float, _pi for its own pi, the rasterizer's target by name, and no
isfinite shim in math.h (the angles' range test already refuses NaN). The
game code's hooks are marked "port:", their include at the end of each
block, and rasterizer_lights.c's loops declare before they act (C89).
The first-person weapon's lens flares are not culled by the world's
frustum (main's new off-screen cull): they are
drawn at the weapon's own projection, which display.viewmodel_fov can make
wider than the world's.
HALO_VIEWMODEL_VIS is HALO_VIEWMODEL_VISIBLE; the settings' descriptions and
help lines say "stock" view and fit their boxes; Video Setup's XML is
written again by ce_menus.py; the README's field of view text is a section
of its own.
The raised limits' and the walk's comments are marked as the port's, with the unverified HAC2 and MCC comparison left out; the walk's says why the index is compared whole, and the once-only log of a frame reaching the limit gets a comment of its own.
Particles of one kind are drawn together, at most 8 bitmaps' worth. A Halo
PC map's particle may have a bitmap a frame: beavercreek_rev_beta's fluid
bursts have up to 56. A debug build halted ("a build_sprites_begin call can
accomodate at most 8 bitmaps") when such particles were in view; a release
build drew the first 8 bitmaps' sprites and not the others. The builds that
play Halo PC's maps now do as a release build does in a debug build too, and
log it once. The Xbox's maps' particles stay within 8, and the Xbox build is
unchanged.
Without its #ifdef HALO_CUSTOM_EDITION, which OpenCE never defines (it
compiled to nothing): the log is for Custom Edition maps
(custom_edition_cache_tags_loaded), the assertion stays for the Xbox's.
(cherry picked from commit afa6413f1e922621cc04e7953e730d5571b3aae6)
25 notes ("left unassigned only by this default arm ... approval pending,
2026-09-27 audit") argued that a variable was never read unset. Where the
arm ends in system_exit they were right and simply go. A release build's
assertions return, though, so where the arm only asserts the variable now
starts with a value (a Custom Edition map's HUD data can reach hud_draw's).
A failed map precache reads as failed.
rasterizer_debug_drawing_begin had two declarations, one with an argument
its definition never takes; it now has one, and the port's macro papering
over the mismatch is gone.
(cherry picked from commit 74f8a048e4c3cc7dbc4b050dd41a8bae912bb367)
The average radius of a group whose particles were all culled divided
zero by zero, leaving a NaN in the effect shader's secondary map radius.
(cherry picked from commit 11128fd78ade85c50a9a3a5a292bd2bb33bebf30)
(cherry picked from commit b52d79541dc2143de41943367542ae63ad4f384f)
Rotational sprites draw their edge-on view from the sequence after the state's. A particle bitmap on foundation has only one sequence, which halted the game in particle_system_render. Without that sequence the face-on sprite is drawn alone.
(cherry picked from commit d436a0c0c3abaf069dd34e4b8d761b49569311e6)
Conflicts: port_config.c (both sides' debug settings), hud_weapon.c (the
VR crosshair filter before upstream's state index check),
first_person_weapons.c (the VR arms kept; upstream's animation node check
added, and its node count limit applied to the VR arms too).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
port/linux/game/vr_graphics.c (after HaloCE-Quest-VR's, CC0) sets the
game's own effect switches each frame before drawing: "high" (the
default) draws everything as before; "medium" no object shadows,
environment reflections or lens flares; "low" nor specular light, bump
maps, detail objects (grass), the screen's fog layer, contrails, weather
or camouflage's second pass; "max" is "high" with per-pixel model
lighting and 512x512 shadow maps (d3d8_gl.c asks halo_vr_graphics). A
switch the game changes (scripts, console) is taken as its wish and
combined with the preset's. A client in another's game keeps grass, lens
flares and the fog layer as the host's rules have them; cheats.c leaves
the environment parts the preset may keep off there (shadows, specular,
reflections).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Conflicts: d3d8_gl.c (multiview variants kept beside the per-pixel lit
shaders: shader[4] and lit_shader[4], vertex_shader_get takes both;
multiview targets before multisampling; the picture read resolves both),
nv2a_vsh.c/xgpu.h (lighting and multiview parameters), render.c (no
anti-aliasing pass on VR eye passes), dsound_sdl.c, p2p.h.
VR: anti-aliasing off (the eyes go to the headset from their textures);
the VR online list skips password games (the server browser asks).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
display.anti_aliasing, off by default: "fxaa" or "smaa" (a pass over the
3D view before the HUD and menus; SMAA vendored from port/third_party/smaa,
MIT), "ssaa2x" (the screen's targets at twice the resolution, at most the
GPU's largest target) and "msaa2x" to "msaa8x". Multisampled framebuffers
have every attachment multisampled, so the mirror's view with the back
buffer's depth buffer is too, and a target's texture and renderbuffer stay
coherent. The setting is read again between frames. Android has FXAA for
SMAA and no supersampling.
Based on #38 and #39 by Tyberious.
At an open vehicle's wheel, a hand that grips near it (where the driver's
drawn hands hold it) takes hold, and the hands turn it about its column:
both by the line between them, one about the wheel's middle. Turned
vr.vehicle_wheel_degrees (90) either way it steers fully; let go, the right
stick steers as before. Holding the wheel, the right grip is no melee.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The desktop builds' mouse in the menus (halo_ui_pointer.h) now comes, on
Android in VR, from a controller: where its aim's line meets the menus'
screen fixed in the room is the pointer, the trigger clicks (the hand
pressed last points; a click ticks its rumble), and a ringed dot shows
where it points. The item under it takes the focus and a click presses A,
as with the mouse; the online games and host options panels take it too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The HUD in VR is a screen at one distance before the eyes, where the names
upstream draws on it hung. Each name is now drawn into a slot of a region
of the back buffer before the HUD (up to eight, one under another), taken
into a names layer, and shown on a quad of its own over its player's head,
facing the eyes, as wide as it would look on the HUD: in depth, for both
eyes. Who is named, and when, is as upstream has it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The disc sits 7 cm over the hand, where a rifle's or pistol's scope is;
over the rocket launcher, carried higher on the shoulder, it was inside
the tube. A weapon may raise it (halo_vr_set_scope_raise): the rocket
launcher by 11 cm.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Upstream's own fixes replace two of ours: reclaiming ART's idle large
object space for the guest's fixed ranges (host_memory.c), and the audio
callback's gathering (host_sdl.c). Its consolidated headers take the VR
declarations (model_animation_definitions.h, render/render.h). The
updaters look at this repository's releases: the original's builds, made
without VR, must never replace this one (they share the package name).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Seated in a level's opening cinematic (a passenger), the right controller
turned the game's camera the flat screen shows. The scripted-camera rule
went back out: the main menu is a scripted camera and was immersive.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A scripted camera outside a cinematic (a level's intro) was drawn in
stereo from the head, with the weapon at the controllers in it; it now
goes to the screen like a cinematic. Under the system menu the headset
reports no hands and the weapon fell back to the head; the hands last
seen in focus stand in meanwhile, their buttons let go.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sprites, light volumes (a plasma bolt's glow) and lens flare tests are
projected on the CPU into screen pixels with w 1 and their depth in z, and
the widgets' vertex program takes them to clip space: taken for a point
1 world unit away, a bolt 30 away stood 3 m off in stereo and seemed to be
swallowed half way. Where w is 1 and depth is tested, the depth comes from
z by the shared camera's projection (mv_depth), and the eye's offset is by
it. (Also logs, once each, the other targets the pass draws into.)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The sky is drawn about the camera (its view has no position), so no eye
stands aside of it; the eye's offset made it a dome a few metres away,
flat and swimming (the sea in 'Halo' is the sky's). Its draws take rows
without the offset.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With GL_OVR_multiview2 (vr.multiview), the scene is drawn once, from a
camera between the eyes whose view takes in both (plus a margin), into a
two-layer back buffer: every NV2A vertex program gets a two-view variant
that moves each view's clip position to its eye (x' = a x + b w + c, from
the shared view's and the eye's edges and the eye's place; nv2a_vsh.c),
screen-space geometry excepted. Sampling the back buffer meanwhile reads
the left eye's picture; visibility counts are halved. The host copies each
layer to its eye's image (host_xr_copy_layer_array).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The game steers a vehicle gun's shots (within its deviation cone) at what
the camera aims at; VR had replaced that camera with the barrel's own
line, right on foot but not seated, where a Banshee's nose rises as it
hovers and a tank's turret lags: the Banshee's crosshair rode high. Seated,
the camera is now the player's eyes and the unit's aim (the stick's steer,
the controller at a gun), and the crosshair floats on that line; the
barrel-line crosshair is gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A vehicle's gun, once manned, fires along its own barrel (not the aiming
vector) from its primary trigger, moved onto the vehicle's camera line if
it fires from its camera. The crosshair ran from the right hand along the
controller instead, and the Scorpion's shells landed above and behind it.
It now floats on the gun's own line (weapon_vr_manned_gun_line), as the
turret actually points.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Their rider bends down into the vehicle, and the eyes at his head looked
into his own shoulders.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Seated as a driver or gunner, the player's body is drawn (its hands on
the wheel or the gun's handles, as the seat animates them), its head
shrunk to nothing out of the eyes' way. A gunner's view is moved back from
the gun's sights (vr.gunner_camera_back). Glass tints and reflects half as
much (vr.glass_strength), which up close hid the view through the
Warthog's windscreen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Seated, the view stays behind the player's own eyes (vr.vehicle_first_person)
and turns with the vehicle, smoothly between ticks (its interpolated
heading); the head looks around freely, and recentring faces the vehicle's
forward. A driver who steers by facing (jeep, boat, plane, scout, fighter)
steers with the right stick: aside up to vr.vehicle_steer_degrees off the
heading, up and down for pitch (vr.vehicle_pitch_degrees). Gunners, the
tank's driver and passengers aim with the right controller, and turn in
the seat with the stick. The crosshair and its distance follow the
vehicle's aim. While the vehicle turns the player, the eye images darken
from their edges (vr.comfort_vignette, host_xr_set_vignette).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The crosshair used to be cut out of the HUD image (an 80x80 region around
the centre) and moved to where the weapon aims, taking with it whatever
else lay there, such as part of the reload prompt. Now it is drawn alone
first (hud_draw_crosshair), captured into its layer, and the HUD is drawn
afterwards without it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- The weapon's own crosshair (red on an enemy, as in the HUD) is taken
from the HUD's centre and floats where the weapon aims, as far away as
what it aims at, facing the eyes, as large as the HUD showed it
(vr.crosshair). The laser is off by default (vr.laser) and never shows
over the menus.
- Zoomed in, the first-person weapon stays in the hand (the game hides
it), the HUD's crosshair and zoom overlays give way to the scope, which
has a fine cross of its own, and the scope's disc is 10 cm across.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Recover transparent geometry submit (+1,285 meaningful code, zero exact losses); reconcile COMMON ownership and Q10 85+EXT1 credit, actions/main data, and separately disclosed denominator corrections. Preserve canonical-only repairs and all held research. C09 is ordinary disclosed cleanup, not a claim of proven scaffolding intent. Clean rebuild, 1,663 tests, parks, audits, provider links and independent EXT1 check pass. Local reconciliation only.
Zoomed in, the player's view is drawn once more, from the weapon along
its aim through the zoom's field of view, into a small square of the
back buffer (the first-person weapon left out), and shown on a disc over
the barrel that magnifies what it covers of the view by the zoom's
magnification (vr.scope_size). The weapon's zoom mask and filters no
longer darken the HUD before the eyes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
