Ami eltér majd a CPC-stől, hogy ott külön palettája van a sprite-oknak, de ez legyen a legkevesebb.
Itt külön paletta - úgy tűnik - nem lesz sajnos, a NICK ezt nem teszi lehetővé. Ezért is lett volna szerencsés, ha az ECx bemenetek kikerülték volna a palettázó áramköröket, és "direkt" mentek volna ki a színkimenetre.
Ez az SPB, SPT ötlet nagyon tetszik, az, hogy meg lehet adni a sprite adat kezdetét, meg méretét főleg, sehol se láttam még ilyet, pl CPC-n fix címek vannak, és ha egy nagyobb sprite-ot akarsz, akkor több kisebből kell összepakolni, és gondolom az SPB tartalmazná a sprite x y pozícióját is.
Azt az "adat-kezdet" dolgot természetesen úgy kell érteni, hogy a bővítés memóriáján belül. Bár gondolom ez egyértelmű.
Egy SPB tartalmazna az adott sprite-hoz minden szükséges adatot a képén kívül, az X/Y pozíciót is. Jut eszembe: ebből lehetne akár több is, ha ugyanazt több helyre is ki akarnád rakni. Így elég lenne csak 1× felolvasni, kirakni meg lehetne több helyre.
A látható sprite-tal kapcsolatban, ha több sprite van ugyanazon a helyen ,vagy félig takarásban, kirajzolná az összeset, csak az utolsót jól rápakolná a többire, így lenne ami látható lenne a régebbiekből is?
Természetesen. Mivel egy-egy pixel egy BYTE-ot használ a "frame-buffer"-ből, így ehhez hardveres segítség is lehet: ha átlátszó a kirakandó pixel, nem történik memóriaírás. De ez már technikai részlet, az meg még odébb van.
ha az ütközés vizsgálat sprite pozíció alapján történik majd, ha pedig két sprite aktív pixelének találkozása alapján, akkor maradhat, de gondolom nem ez lesz, mert ehhez egy erőmű kéne.
Az esetleges ütközésvizsgálat mindenképpen kapcsolható kell hogy legyen, mert ebben a felépítésben rendesen viszi az erőforrást.
De pixeles találkozás alapon gondolom a vizsgálatot, ahhoz viszonylag egyszerű és jól optimalizálható a matek. (Így, első végiggondolásra legalábbis...
)
Azert ne felejtsuk el, hogy itt ez egy hardware Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit,
Ja, de itt pont nem hardver az ütközésvizsgálat. Bár... Most hogy mondod, DE!
Csinálható ehhez "egyszerű" hardveres segítség, ismét egy megjegyzendő ötlet!
És ahol két EXTC találkozik, az már adja a jelet, hogy az aktuális sprite nekiment valaminek.
Ez igaz, ha a "világon eddig használt" "real-time" verzió van megvalósítva. Ha a "saját" verziómat nézem, ott nincs több párhuzamos EXTC jel, csak egy van.
If a fast processor is used for sprites, why not implement some simple form of maths coprocessor? Of course in floating point BCD...
Ha van a külső µC, akkor azt lehet használni koprocesszornak is, persze. Mondjuk én nem biztos, hogy FPU-nak használnám elsősorban, hanem inkább
blitter-nek. Persze a kettő nem zárja ki egymást.
Kicsit ott-topic, de: https://www.youtube.com/watch?v=h42neZVvoMY
Hát igen, eléggé "félőrült" a jóember... (Persze a jó értelemben.)
