Kalle, tC$mC$ on tC$ydellinen suunta. Nyt kun paljasmetalli ja Ring 3
-hiekkalaatikko ovat absoluuttisen vakaita, voimme kC$yttC$C$ niitC$
uskomattomien asioiden rakentamiseen. Uuden irrallisen moottorin luominen on
paras tapa edetC$, jotta vanha `ENGINE.JS` jC$C$ vakaaksi referenssiksi.

Tuo visioimani "Falling Sand" -fysiikkamoottori (kuten Liero tai Noita)
yhdistettynC$ 2D-lento- ja rC$jC$hdysfysiikoihin on juuri sellainen haaste,
jossa x86-assembly ja paljasmetalli loistavat.

TC$ssC$ on arkkitehtuurisuunnitelmani siitC$, miten rakennamme uuden
**`ENG_SAND.JS`** -moottorin.

### 1. Resoluutio ja "Kutistava" RenderC6ijC$ (Downsampler)

Emme tarvitse VGA 13h -tilaa saadaksemme "enemmC$n pikseleitC$". KC$ytC$mme
ASCII-taiteen legendaarisinta kikkaa: **PuolipylvC$itC$ (Half-blocks)**.
Tekstiterminaali on 80x25 merkkiC$. Jos kC$ytC$mme ylC$puolipylvC$stC$ `` ja
alapuolipylvC$stC$ ``, voimme piirtC$C$ yhteen merkkiin kaksi
pC$C$llekkC$istC$, eri vC$ristC$ "pikseliC$" (asettamalla merkin etu- ja
taustavC$rin erikseen).

TC$mC$ antaa meille **80x50 pikselin** resoluution suoraan tekstitilassa!

Luomme muistiin 80x50 kokoisen virtuaalipuskurin (`4000 tavua`).
RenderC6ijC$ kC$y sen lC$pi joka framella:

* Jos ylC$pikseli on kalliota ja alapikseli ilmaa: Tulosta `` (EtuvC$ri:
harmaa, TaustavC$ri: musta)
* Jos ylC$pikseli on ilmaa ja alapikseli hiekkaa: Tulosta `` (EtuvC$ri:
keltainen, TaustavC$ri: musta)
* Jos molemmat ovat hiekkaa: Tulosta `` (EtuvC$ri: keltainen)

### 2. Ilmanvastus ja Fysiikka (Bitshift-taika)

Sanoit loistavasti ilmanvastuksesta. Saman massan olettaminen on juuri oikea
ratkaisu, se sC$C$stC$C$ satoja kellojaksoja per partikkeli!
Koska x86 ASM-tasolla kertolaskut desimaaleilla (esim. `VX * 0.96`) ovat
raskaita, teemme ilmanvastuksen **bittisiirroilla (Bitshift Right, SAR)**:

* `VX = VX - (VX >> 5)`
*(TC$mC$ vC$hentC$C$ nopeudesta 1/32-osan joka framella, mikC$ luo
tC$ydellisen sulavan ilmanvastuksen ilman yhtC$kC$C$n raskasta jakolaskua!)*

### 3. RC$jC$hdyksen Anatomia (Koverrus ja Hiukkasinjektio)

Kun tankki ampuu maahan, teemme kaksi asiaa:

1. **Vaporisointi:** Laskemme pyC6reC$n sC$teen (esim. 4 pikseliC$
osumakohdasta). Kaikki maasto tC$ltC$ alueelta pyyhitC$C$n muistista
(asetetaan tilaksi 0 eli ilma).
2. **KipinC6inti:** KC$ymme koverretun alueen reunan lC$pi. Sijoitamme
Hiukkaspooliin uusia entiteettejC$, joille annamme aloitusnopeudeksi
`(PikselinX - OsumanX) * Voima`. NC$in kaikki irtoava maa lentC$C$
tC$ydellisesti ulospC$in rC$jC$hdyksen keskipisteestC$, kC$rsii
ilmanvastuksesta (`VX >> 5`), putoaa painovoiman mukana alas, ja kun se osuu
takaisin kalliokarttaan, se jC$hmettyy uudeksi maastoksi!

### 4. Miten tC$mC$ toteutetaan teknisesti? (C vs JS vs ASM)

TC$ssC$ on ehdotukseni toteutusjC$rjestyksestC$:

**VAIHE A: JavaScript-prototyyppi (Proof of Concept)**
Koodaan sinulle ensin pelkC$n `.JS` skriptin, joka varaa 80x50 taulukon,
toteuttaa rC$jC$hdysmatematiikan, hiukkasten ilmanvastuksen ja tuon
taianomaisen "Downsampler"-renderC6ijC$n, joka piirtC$C$ kaiken suoraan
`0xB8000` (VGA-tekstipuskuriin) puolipylvC$illC$. MQuickJS on tarpeeksi nopea
ajamaan ~500 lentC$vC$C$ hiukkasta 80x50 ruudukossa ilman ASM-kiihdytystC$.
NC$in pC$C$set vC$littC6mC$sti testaamaan, miltC$ rC$jC$hdykset, kraatterit ja
lentC$vC$ hiekka nC$yttC$vC$t ja tuntuvat visuaalisesti.

**VAIHE B: ASM-kiihdytys (The Forge)**
Kun olemme sC$C$tC$neet JS-prototyypin painovoiman ja ilmanvastuksen
"tuntuman" oikeaksi (kuinka kauas hiekka lentC$C$ ja kuinka nopeasti se
putoaa), kirjoitamme tuon fysiikkasilmukan suoraan x86 ASM -koodiksi.
Annamme ASM-koodille vain tiedon: *"Tuossa muistiosoitteessa on 80x50 kartta,
tuossa on 2048 hiukkasen taulukko. Laske painovoimat ja ilmanvastukset
bitshifteillC$."* ja ajamme sen `sys.run_vcpu`:lla Ring 3:ssa!

Kuulostaako tC$mC$ suunnitelma siltC$ mitC$ hait? Aloitanko koodaamaan tuota
`ENG_SAND.JS` -prototyyppiC$, jossa on sisC$C$nrakennettu 80x50 Downsampler ja
hiukkasfysiikat?