test26 — der Speicherbedarf ist ungefaehr halbiert

Der Speicherbedarf ist ungefaehr halbiert

Gemessen an Crazy Castle: vorher 160 MB, jetzt 105 MB aus dem System
genommen. Heide Park mit 2.075 Gaesten: vorher 174 MB, jetzt 94,5 MB --
der grosse Park ist jetzt der leichtere von beiden. Damit ist die
128-MB-Grenze erreicht, und das ist das Maximum der meisten klassischen
Turbokarten.

Schneller wird nichts davon, das war auch nicht das Ziel: die Bildrate ist auf
allen drei Maschinen unveraendert.

Was sich geaendert hat

Zwei feste Tabellen hatten immer ihre maximale Groesse, egal wie klein der
Park war: die Gaeste-Plaetze (22,5 MB) und die Fahrgeschaefte (14,5 MB, davon
13,3 KB pro Fahrgeschaeft allein fuer 255 Stationen). Beide werden jetzt
stueckweise angelegt. Heide Park braucht davon 880 KB und 930 KB statt 37 MB.

Grosse Bloecke (ueber 256 KB: Objektgrafiken, Dateipuffer, Autosave) gingen
bisher in den eigenen Heap und blieben dort bis zum Programmende liegen. Sie
gehen jetzt direkt an exec und kommen beim Freigeben zurueck. Das sind die
restlichen 54 MB.

Falls etwas komisch aussieht

Der zweite Punkt war seit test19 abgeschaltet, weil es damals auf einer V4
zerhackten Text gab -- ab test17, dem ersten Build mit diesem Verhalten. Das
Problem ist seit test19 weg und wurde nie sicher auf diese Sache
zurueckgefuehrt, aber bewiesen ist nichts. Wenn die Darstellung kaputt aussieht:

SetEnv OPENRCT2_NO_BIGALLOC 1

und neu starten -- dann verhaelt sich der Speicher wie in test25. Bitte sagt mir
Bescheid, wenn ihr das braucht.

Worauf ich besonders schauen wuerde

1. Sieht der Text ueberall normal aus? Menues, Fenster, Geldanzeige,
   Objektiv-Beschreibung.
2. Gibt das Spiel den Speicher wieder her? Avail vor dem Start merken,
   spielen, sauber ueber Exit OpenRCT2 beenden, Avail nochmal. Die Zahl
   sollte wieder dort sein, wo sie vorher war. AmigaOS holt sich Speicher von
   einem beendeten Programm nicht selbst zurueck. Genau dieser Fehler war im
   ersten Anlauf drin -- auf einem A4000 lagen 153 MB fest, ohne dass das Spiel
   lief, und keiner der vier Emulator-Pruefdurchlaeufe hat es gesehen. Erst die
   echte Maschine. Ist behoben.
3. Ganz normal spielen -- Abstuerze, Einfrieren, kaputte Grafik melden.

Bildrate, gemessen

Gleicher Park, gleiche gespeicherte Kameraposition auf allen Maschinen.
Bildratenbegrenzung liegt bei 40.

Park	Gaeste	Emulator	PiStorm	A4000 / 68060 @ 100 MHz
Crazy Castle	3	35-38	39-40	36-37
Extreme Heights	172	34-39	38-40	32-35
Heide Park	2.085	15-16	16-18	2-3
Ladezeit		26-32 s	27 s	161-205 s

Ein normaler Park laeuft auf allen dreien an der Begrenzung. Bei 2.000 Gaesten
ist nur der PiStorm in der Naehe von spielbar.

Zwei Archive

• ...-amiga68k.lha -- vollstaendig, fuer eine Neuinstallation.
• ...-amiga68k-update.lha -- nur Programm und Doku, ueber eine
  bestehende Installation entpacken; config.ini und die Caches in user/
  bleiben erhalten.

Die RCT2-Daten sind wie immer nicht enthalten.

Alle Messungen von heute: https://claude.ai/artifact/J2CsgHAn1jucfm5G9NX4CC

test25 — superseded by test26

The frame-rate counter works again where it was broken, and painting no longer pretends to have more than one core.

Correction to the first version of these notes: they said the counter drew nothing on every machine. That is wrong, and two testers said so straight away: it worked for them on test24. It failed on the emulator here and for at least one tester. The reason it differs per machine is the second half of this note.

The counter. On the machines where it failed, it was not the counter: everything drawn straight to the screen instead of through a window was being skipped for the whole session, the counter and the replay notice included. The screen's drawing state has an origin that is 0,0 by definition and that nothing in the game ever moves, and a stray four-byte write clobbers it about twelve seconds into start-up. The text layer asks whether a string lies outside the target before drawing it; with a garbage origin every string counted as off-screen, so the layout ran and the glyphs did not. test25 repairs that field every frame and no longer lets one corrupted word turn into "no text anywhere".

The stray write itself is not found, and it is the real bug here. Where those four bytes land depends on how the heap happens to be laid out, which is why the same build loses the counter on one machine and not on another. It repeats to the same value across runs on a given machine, and it does not happen with sound switched off, although switching sound off also moves every later allocation, so that may only mean the damage lands somewhere harmless. It is not the paint threads, not the text formatter's buffer, not the progress window's widgets, and the mixer does not write past the buffer it is handed. If your trace ever shows the line "gfx: main render target origin was clobbered", that is the write hitting the screen state on your machine, and we would like to know. Garbled text or menu entries that turn into nonsense is what the same write would look like if it lands somewhere else.

One core. Painting the view split its work across worker threads by default. The 68k machines this runs on have one core, so that only bought context switches and a lock around every drawing call. It is off by default now and still switchable in the options. On the emulator a 2,070-guest park went from 27.2 to 28.2 frames per second and from 31.4 to 30.1 milliseconds per simulation tick.

Everything from test24 stays in. Checked on an emulated 68040 before release: sound health, title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit.

Note that deleting config.ini resets show_fps to false, so set it again afterwards.

The -update.lha unpacks over an existing install; the full archive is for new installs.

test24 — big parks become usable, faster start

Big parks become usable, and the game starts faster.

Big parks. A park with a couple of thousand guests spends far more time on one simulation tick than on a whole frame, and the game ran up to four ticks back to back before drawing once. The picture and the mouse froze for the length of four ticks, which is why a 2,000-guest park drew about one frame per second. The game now draws after every tick when a tick is that expensive. In game time the park does not run faster, but you can see it and click in it. On an emulated 68040 a 2,070-guest park went from 3 to 32 frames per second. Nothing about the simulation changed: every tick that runs is a whole, ordinary tick, in the usual order.

The game stopped measuring itself. Every guest was being timed with two system-clock reads on every tick, whether or not you had asked for a trace. In a 2,000-guest park that is a quarter of a million clock reads a second, and on a PiStorm a clock read crosses the bus. The measurement now only runs while a trace is being written. On the emulator that took a quarter off the cost of a tick, and it should help more on real hardware than it does there.

Starting up. Files are now read the Amiga way rather than the way the C library suggested: the directory scan asks AmigaDOS for a file's name, size and date in one call instead of six, the read buffer is 64 KB instead of 1 KB, and the file layer no longer asks AmigaDOS where it is before every single read. Reading the 35 MB of object data for a scenario went from 2.0 to 0.4 seconds, and the whole start from 40 to 31 seconds on the emulator. On a machine where that read took 23 seconds it should be worth a good deal more.

Everything else from test23 stays in. Checked on an emulated 68040 before release: sound health, title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit, and a memory soak.

If the new frame pacing misbehaves on your machine, SetEnv OPENRCT2_NO_TICKCAP 1 puts the old behaviour back; please tell us if you need it.

The -update.lha unpacks over an existing install; the full archive is for new installs.

---

Superseded by test25, which fixes the frame-rate counter (it drew nothing in test24 and earlier).

Tester build 23 (freeze fixed on PiStorm/Emu68, rain fix)

The good build, plus one more bisect step and a rain fix.

test22 ran on Markus' PiStorm without a freeze (title park with music, Forest Frontiers at 40 fps, clean exit), which narrows the freeze to one of three test15 changes. test23 keeps only the most likely one out, the memoised path scan, and puts the other two back (inlined palette lookups, direct blitter dispatch). Confirmed on two PiStorms: no freeze. The memoised path scan was the cause on Emu68 and stays out; big parks simulate about 15% slower without it, ordinary parks not measurably. This is the recommended build.

Also fixed: rain and snow animated only where something else on screen was changing (a dirty-block blitting bug); the whole screen is now updated while weather is drawn.

Everything else from test22 stays in (sound in its own process, memory as in test16, track designs, cursors, clipboard, FPU variant). Checked on an emulated 68040 before release: sound health, title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit.

The -update.lha unpacks over an existing install; the full archive is for new installs.

---

Superseded by test24, which starts faster and makes big parks usable. test23 is still freeze-free; there is no reason to stay on it.

Tester build 22 (freeze bisect: test14 path finder and blitter dispatch back)

Superseded by test23, the first build since test14 confirmed freeze-free on PiStorm/Emu68 (two testers). Use the newest build from the releases page.

Freeze hunt, round three (PiStorm/Emu68, freeze a few seconds into the title park since test15).

Markus' runs so far exclude sound, the memory change, entity drawing, the tile cull and the heap statistics. All three traces stop in the same 40-tick window after the park starts, which points at a game event rather than at rendering. test22 therefore backs out the last test15 changes that had no switch: the path finder is the test14 version again (the memoised tile scan is gone, big parks simulate about 15% slower), the palette lookups are out of line again, and the paint loop goes through the normal dispatch again. What remains of test15 is switchable: OPENRCT2_NO_RLE_FAST 1 (sprite loop) and OPENRCT2_NO_SURFACE_CULL 1.

If test22 survives the title park, the cause is in what was removed and I split it further; if it freezes, one of the two switches names it.

Everything from test21 stays in otherwise. Checked on an emulated 68040 before release: sound health (1,000 requests, 3 underruns), title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit.

The -update.lha unpacks over an existing install; the full archive is for new installs.

Tester build 21 (freeze bisect: heap walk only while tracing, switches)

Superseded by test23, the first build since test14 confirmed freeze-free on PiStorm/Emu68 (two testers). Use the newest build from the releases page.

Freeze hunt, round two.

Markus bisected the PiStorm freeze to test15 (test14 runs, test15 hangs about five seconds into the title park at 100% CPU; from test16 on the same hang takes the sound with it). Sound, memory handling, guests and vehicles are ruled out by his runs. The remaining test15 suspect that depends on the machine rather than on the park is the heap statistics walk the game did every 100 frames for the trace line, whether or not a trace was written. test21 does it only while a trace is written, and can skip it even then.

Bisect switches in this build, each SetEnv NAME 1 in the Shell before starting: OPENRCT2_NO_HEAP_STATS, OPENRCT2_NO_RLE_FAST (generic sprite loop), OPENRCT2_NO_TILE_CULL, OPENRCT2_SKIP_ENTITIES, OPENRCT2_NO_AUDIO. Guide section 6 lists them.

Everything from test20 stays in.

Checked on an emulated 68040 before release: sound health (1,000 requests, 3 underruns), title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit.

The -update.lha unpacks over an existing install; the full archive is for new installs.

Tester build 20 (freeze fix: AHI playback in its own process)

Superseded by test23, the first build since test14 confirmed freeze-free on PiStorm/Emu68 (two testers). Use the newest build from the releases page.

Freeze fix.

Markus (PiStorm/Emu68) and Nils saw the whole Amiga freeze a few seconds into a park since test16, the sound looping its last milliseconds. test16 was the first build that played sound continuously, and its driver broke a rule of the AHI autodocs: it could link a new request to one that had already finished. Paula under Emu68 hangs on that; the Vampire's driver does not mind, which is why Stefan never saw it. Sound now runs in its own process ("OpenRCT2 audio") that double-buffers exactly as the autodocs show, fed from a ring buffer by the game.

The emulator never reproduced the freeze, so please report whether it is gone. If a machine still freezes, SetEnv OPENRCT2_NO_AUDIO 1 before starting confirms whether the sound path is involved.

Everything from test19 stays: memory behaves as in test16 by default, track designs work, tool cursors and the clipboard, and bin/openrct2-fpu for machines with an FPU.

Checked on an emulated 68040 before release: sound health (1,000 requests, 3 underruns), title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit.

The -update.lha unpacks over an existing install; the full archive is for new installs.

Tester build 19 (safe default: memory as in test16)

Superseded by test20: builds test16 to test19 can freeze the whole machine on PiStorm/Emu68 after a few seconds of sound. Use the newest build from the releases page.

Safe build for the wider audience.

test17 changed how the game hands memory back to the system, and one tester (Vampire V4) has seen garbled or missing menu text since, up to not being able to quit. The emulator does not reproduce it and the cause is still open, so test19 turns that change off by default: memory behaves as in test16. Testers who want to help pin it down can switch the new path on with SetEnv OPENRCT2_BIGALLOC 1 in the Shell before starting and report whether text breaks.

Everything else from test17 and test18 stays in: track designs work (they never did on the 68k before), the track design list no longer costs 123 MB, ride windows and the construction window are cheaper while building, tool cursors are shown through the OS pointer, Ctrl+C/X/V works in text boxes, and bin/openrct2-fpu is a third program file for machines with an FPU (guide section 2e).

Checked on an emulated 68040 before release: sound health, title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit.

The -update.lha unpacks over an existing install; the full archive is for new installs.

Tester build 18 (diagnostic switch, cursors, clipboard, FPU variant)

Superseded by test20: builds test16 to test19 can freeze the whole machine on PiStorm/Emu68 after a few seconds of sound. Use the newest build from the releases page.

Superseded by test19, which turns the suspected memory change off by default (no Shell variable needed). Use the newest build from the releases page.

Diagnostic and feature build.

• Stefan reports garbled and missing text with test17 on a Vampire V4, which the emulator does not reproduce in either language or binary. The one memory change in test17 (large freed blocks go back to the system) can be switched off at run time in this build: type SetEnv OPENRCT2_NO_BIGALLOC 1 in the Shell before starting. If that fixes the text, please say so; it points straight at the cause.
• Mouse cursor shapes: the game's tool cursors (hand, bulldozer, path, water, ...) are now shown through the OS pointer (Intuition pointerclass). New and only verified to not crash on the emulator; how it looks needs your eyes.
• Text clipboard: Ctrl+C, Ctrl+X and Ctrl+V in text boxes exchange text with other Amiga programs (clipboard.device, FTXT).
• bin/openrct2-fpu: a third program file compiled for a 68060 with hardware floating point. Needs an FPU (68040/68060 with FPU, PiStorm, Vampire); it will not start on LC chips or a plain 68020/030. The game avoids floats in its hot paths, so the gain may be small. Guide section 2e.

Checked on an emulated 68040 before release: sound health, title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit. The FPU variant was started, run and exited on the emulator.

The -update.lha unpacks over an existing install; the full archive is for new installs.

Tester build 17 (memory, track designs, building rides)

Superseded by test20: builds test16 to test19 can freeze the whole machine on PiStorm/Emu68 after a few seconds of sound. Use the newest build from the releases page.

Known problem: one tester (Vampire V4) sees garbled or missing menu text with this build and cannot quit the game. Not reproducible on the emulator yet. Please use the newest build from the releases page instead; test19 turns the suspected memory change off by default.

Memory, track designs and building-rides build, from Stefan's V4 trace (thanks!).

• Track designs work now. The design files are little-endian and were read raw on the 68k, so entrances landed at wrong positions, placing a design failed (the 'Entrance/exit element not found' and 'Invalid operation option value' errors in the trace), the design list's preview stayed blank and the ride length and cost were wrong. All of that is fixed: the list shows the design picture, sensible numbers and the design places.
• Opening the track design list used to take 123 MB for good (the preview reserved room for eight elements on every tile of the largest possible map). Fixed, and the memory manager now hands blocks of 256 KB and more back to the system when they are freed: on the title screen the game's footprint is 163 MB instead of 219 MB, and big transients such as autosaves no longer stick.
• While building rides: a ride window whose view follows a vehicle now moves every other frame instead of every frame (27 ms each on a V4), and the construction window keeps its track piece preview instead of repainting it (60 ms) on every redraw.
• The title screen tours two parks for two minutes each instead of four parks for 45 s; every park change costs 30-70 s on real hardware and read as "5 fps".
• Trace: the start-up now logs the base graphics stages and the object load line splits file reads from decoding, so the next traces tell whether an object cache would help.

Checked on an emulated 68040 before release: sound health, title screen, audio content, Crazy Castle static and scrolling frame rate, the 1,560-guest park, clean exit, plus a 21-minute soak.

The -update.lha unpacks over an existing install (bin/openrct2, bin/openrct2-o2, data/sequence/Amiga.parkseq, the docs); the full archive is for new installs.