The Field and Its Size

The BPT law

BPT Part 1.9, The UniSpheral Grid, holds that every reality is a view of one grid of invariant pixels. The pixel itself never changes: the UniSpheral Pixel Size, 🟑 = κ_z × 𝒞→ × ℨ, is "constant across all Universe levels," and "what appears as different realities are simply different zoom factors and frame rates viewing the same computational substrate." What changes with the level is how many pixels a view holds. The UniSphereal Harmonic Level Architecture states it as the Local Pixel Count (Level N) (G):

🟑⌂(N) = 16 × 2^(2N) pixels per view

"Visible pixel count grows fourfold with each harmonic level: the square of the doubling, 2^(2N) = (2ᴺ)²." The 16 is the "base pixel multiplier; fundamental pixel count at lowest observable harmonic level." At our level the count lands on the Holographic Pixel Bound, 🟑⌂(202) = 16 × 2^404 ≈ 6.6 × 10¹²², about as many pixels as the cosmological horizon holds bits. Since 16·4^N = (4·2^N)², a square view is 4·2^N pixels a side.

BPT Part 3.6 ties this count to the Data Nova: the data "pours out onto space that holds exactly χ_∂ places, one for every bit, so a universe's field is built to the size of its data before its data arrives, with nothing tuned to make it so; this count is the Local Pixel Count, 16·4^L." The field's size is therefore a law of the theory.

BPT does not state a model level. Drawing a deep universe on a smaller field, with its physics read from its true level, is a game method. It serves Part 1.9's own reading of levels as zoom factors on one grid.

The established physics

None: a game method. The field is a square periodic lattice, the usual setting of a two-dimensional cellular automaton (Gardner 1970, Conway's "Life"; Wolfram 2002, A New Kind of Science). Its periodic edges are the torus of Part 2.9.

The game's math

• viewSide(N) = 4·2^N universe.js:232, the side of the field at level N.
• side = max(4, min(1024, viewSide(uni.Lm))) app.js:2052, applied in recomputeUniverse() only while the game is not running. gridSize = side, then updateDimensions() app.js:3594 sets rows = cols = gridSize.
• uni.Lm = min(uni.L, MODEL_LEVEL()) in scaleModel() app.js:4246, with MODEL_LEVEL() = isPhone() ? 4 : 6 app.js:4244. isPhone() app.js:4243 is true when the screen's shorter side is at most 480 px or the browser names itself a phone.
• createGrid() app.js:3618 builds the field's arrays, each rows × cols:
  • grid, the lit state of each cell, 0 or 1;
  • pulserGrid, 1 where a cell has ever pulsed, 0 where it is ∅, the Pre-Pulse Field;
  • exposureGrid, a null cell's exposure toward bifurcation (Part 2.2);
  • colorGrid, each cell's color as a hex string, the data's lineage;
  • foldGrid, 1 where a cell folded on the last flip (drawing only);
  • five legacy arrays kept from earlier versions: residueGrid, lastStateGrid, potentialGrid, emergentGrid, decayGrid. None of them is written by the v8.3 cell rule.
• resizeGrid() app.js:3626 keeps the overlap of the old and new fields (anchored at row 0, column 0) and fills the rest empty.

Level 28 on a desktop: Lm = 6, so the field is 4·2^6 = 256 cells a side, 65,536 cells. The true level's field would be 4·2^28 ≈ 1.07×10⁹ cells a side, about 1.15×10¹⁸ cells. On a phone the same universe is drawn at Lm = 4: 64 a side, 4,096 cells.

Before a universe is described, init() app.js:5415 sets gridSize = isMobile ? 64 : 256, and the page variable starts from the input's default text, '250' app.js:3420. Both are overwritten by side at the first recomputeUniverse(). app.js still carries a handler for a grid-size input (app.js:5565) that would take any positive size typed by hand, but the v8.3 page (index.php) has no element with that id, so on the live page the field always follows the level.

In the game

The level is set before Start with the Level slider in the Universe & Genesis section, 0 to 202, starting at 28 (index.php:145). The section's note says "Set the origin before Start. These lock at genesis, as a universe's do" (index.php:139). Each change of level rebuilds the field at its new side while the game is stopped, so the player sees the field grow fourfold in area with each level from 0 to 6 on a desktop (4, 8, 16, 32, 64, 128, 256 cells a side) and then stay at 256 cells a side for every deeper level.

The readout reports the scale. Its Level line reads the level, the generation, and, when L > Lm, "drawn at 256 cells across" (updateHud() app.js:2144); its tooltip says "deeper than level 6 (4 on a phone) the field and clock are a scale model" (index.php:81). The About panel's card reads "The field follows the level: 4·2^L cells a side, from the Local Pixel Count. Zoom is the only free control" (index.php:301).

The View menu chooses how the field is shown (index.php:141). "2D · the field" draws it as a flat square of cells, with grid lines on by default and a Zoom slider that sets the cell size. "3D · the torus", the default, wraps the same field as a texture: on the Pulsecore sphere before the Data Nova and on the horn torus after it (Part 2.9), with Zoom moving the camera. In 3D the lattice drawn over the torus follows the true level rather than the drawn one: setLatticeLevel(uni.L) (app.js:2043, scene3d.js:1223) draws 4·2^L lines a side, as many as the screen can separate, and shows the rest as a brighter sheet. At level 28 the lattice reads as a sheet while the field under it is 256 cells across.

The painted Pulsecore is the field before Start: the Brush, Pulse Injector and Pattern Stamper tools (index.php:235–239) write cells onto it, and right-click erases.

The scale model

The field is a scale model whenever L > Lm. One drawn cell stands for 2^(L−Lm) true cells along each side, 4^(L−Lm) in area (4^22 ≈ 1.76×10¹³ at level 28 on a desktop). The universe's laws keep the true level (uni.L); the field, the clock (Part 2.3) and the Pulsecore (Part 2.4) run at uni.Lm.

Where the game and the theory differ

• The About card says the field is "4·2^L cells a side." The drawn field is 4·2^Lm a side; at L > Lm it is 2^(L−Lm) times narrower than the Local Pixel Count's view.
• One HUD line does not follow the scale model. updateHud() app.js:2137–2138 shows "1 cell = (f^L/4)·scale ℨ" with the true L, which is the size of a true cell. A drawn cell at level 28 on a desktop is 2^22 of those across, so the line understates a drawn cell by 2^(L−Lm).

Fixed numbers