UCSD Pascal:

https://archive.org/details/UCSD_Pascal_1.1_1

Wizardry:

https://archive.org/details/WizardryProvingGrounds

https://en.wikipedia.org/wiki/SWEET16

I agree with the article's main lessons: wasm32 pointer size, don't serialize structs with pointers, debug native 32-bit when you can, WebGL/WebGPU is stricter than desktop GL, Emscripten export flags still bite. I hit some of the same categories; the parts that were actually tricky for Micropolis are below.

Svelte 5 runes ($state, $derived, etc.) work in plain .ts modules, not just .svelte templates. That matters because the WASM bridge is a reactive module the HUD, command bus, and Vitest all import -- not a component-only trick. The file has to be MicropolisReactive.svelte.ts so runes compile under the same Vite/SvelteKit pipeline as the app; plain .ts breaks in Node with "$state is not defined".

Embind API surface -- what to expose and what to leave out:

https://github.com/SimHacker/MicropolisCore/blob/main/packag...

  // This file uses emscripten's embind to bind C++ classes,
  // C structures, functions, enums, and contents into JavaScript,
  // so you can even subclass C++ classes in JavaScript,
  // for implementing plugins and user interfaces.
  //
  // Wrapping the entire Micropolis class from the Micropolis (open-source
  // version of SimCity) code into Emscripten for JavaScript access is a
  // large and complex task, mainly due to the size and complexity of the
  // class. The class encompasses almost every aspect of the simulation,
  // including map generation, simulation logic, user interface
  // interactions, and more.

The engine callback virtual interface bridged C++ to JS via JSCallback:

https://github.com/SimHacker/MicropolisCore/blob/main/packag...

In the old NeWS/Hyperlook, TCL/Tk/X11, SWIG/Python/PyGTK, and SWIG/Python/TurboGears/AMF/Flash versions, this callback interface used to be a stringly typed general purpose event callback interface, which I tightened up into a strict C++ interface and corresponding typescript interface, so embind could help me integrate it safely and cleanly with TypeScript and Svelte Runes.

TypeScript handlers that update rune-backed state (sendMessage, didTool, budget hooks, etc.):

https://github.com/SimHacker/MicropolisCore/blob/main/apps/m...

Simulator attach/detach, singleton engine load, wiring JSCallback into Micropolis:

https://github.com/SimHacker/MicropolisCore/blob/main/apps/m...

The pattern: C++ fires callbacks with enough context for the UI; TS updates $state; components read micropolisReactive (peek / poke / memory / getSnapshot) instead of calling Embind or touching HEAP* directly. That is where the rubber hits the road for interactivity.

Heap access is its own footgun. Emscripten may expose Module.wasmMemory, HEAPU16, or neither until init; some getters throw if you read too early. Centralized helper:

https://github.com/SimHacker/MicropolisCore/blob/main/apps/m...

Bridge design, Vitest against real WASM, teardown order with Embind lifetimes:

https://github.com/SimHacker/MicropolisCore/blob/main/docume...

Map rendering: WebGPU tile renderer with canvas fallback (legacy WebGL frozen, now reimplementing in WebGPU). The renderer reads 16 bit flags + tile indices from direct simulator memory views into WASM linear memory (mapData / mopData), not per-frame Embind copies.

https://github.com/SimHacker/MicropolisCore/blob/main/packag...

https://github.com/SimHacker/MicropolisCore/blob/main/docume...

City saves are a defined binary format (.cty), not fwrite of engine structs. Live map data is views into WASM linear memory (mapData / mopData), not embedded native pointers -- same idea as the article's side-table fix, but that is how this codebase is already structured.

Why I find this stack interesting: original SimCity engine lineage, narrow Embind surface on purpose, reactive TS facade so automation and UI share one sim without reviving the old Python/SWIG/pyGTK path. Sprites (trains, choppers, generic orange monsters wrecking chaos and havoc -- definitely not Godzilla [TM], but possibly Trump adjacent) simulate in C++; compositing them in the WebGPU path is still work in progress.

The WebGPU renderer is being built as a general stack with pluggable layers, including Sims content rendering (characters, animations, terrain, objects, walls, floors, ui effects, etc).

Character animation demo:

https://vitamoo.space

VitaMoo code:

https://github.com/SimHacker/MicropolisCore/tree/main/packag...

Unified WebGPU Renderer:

https://github.com/SimHacker/MicropolisCore/blob/main/docume...

Render Core Package:

https://github.com/SimHacker/MicropolisCore/blob/main/docume...

Renderer Plugin Roadmap:

https://github.com/SimHacker/MicropolisCore/blob/main/docume...

Live Micropolis tile renderer and simulator demo (no other ui yet, work in progress):

https://micropolisweb.com

Demo of the simulator, cellular automata, and tile engine to Jerry Martin's music:

https://www.youtube.com/watch?v=319i7slXcbI

Repo:

https://github.com/SimHacker/MicropolisCore

https://www.youtube.com/watch?v=D1sXuHnf_lo

Did you ever have one of those days when variables didn't and constants weren't?

There were two buttons, one labeled "Our Web Site", the other labeled "Our Competitor's Web Site".

When you moved the mouse over the "Our Competitor's Web Site" button, it would quickly slide out from under your cursor before you could click it!

Then when you stopped moving your mouse, the "Our Web Site" button would slyly slide right underneath your mouse!

Dammit Microsoft!!! ;)

https://www.youtube.com/watch?v=Qc7HmhrgTuQ

Perhaps VI would make a good snake name, though: VIper.

DonHopkins on May 10, 2019 | parent | context | favorite | on: Why are 2D vector graphics so much harder than 3D?

Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other:

https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us...

>By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools.

The Definitive History of PostScript

https://github.com/SimHacker/moollm/blob/main/designs/postsc...

>Primary Source: Brian Reid's 1985 "laser-lovers" Post

>This document preserves the definitive first-person account of PostScript's origins, written by Brian Reid on March 2, 1985 — just 11 months after Adobe shipped its first PostScript manual.

>Brian Reid was uniquely positioned to write this history:

>He was there. As a consultant to Xerox PARC during the Interpress design, he worked directly with the principals.

>His thesis advisor was Bob Sproull — one of the three architects of Interpress (with Butler Lampson and John Warnock).

>He saw JAM at Stanford in 1981 — the direct predecessor to both Interpress and PostScript.

>fa.laser-lovers was the Hacker News of 1985 — this wasn't a casual post but a definitive statement to the technical community.

rustcleaner> I was an early bird in MGTOW, but now it's common knowledge and operating strategy for most young men.

So how's that book of racist poetry you're writing going? Has it impressed the ladies and helped with your incelibacy problem?

https://en.wikipedia.org/wiki/Self-licking_ice_cream_cone

>In political jargon, a self-licking ice cream cone is a self-perpetuating system that has no purpose other than to sustain itself.

>History

>The phrase appeared to have been first used in 1991–1992, in a book about Gulf War weapons systems by Norman Friedman, and On Self-Licking Ice Cream Cones, a paper by Pete Worden about NASA's bureaucracy, to describe the relationship between the Space Shuttle and Space Station.

[...]

rustcleaner> homosexual and transsexual topics

OK boomer.