Zgaduję: Górne to Amiga, dolne ST. A to z racji ewidentnego wykorzystania Coppera - oddzielnej części oprazu na górze, której nie trzeba aktualizować.

A teraz w drugą stronę. Górne to ST, bo na dolnym w lewym górnym rogu mamy Sprajty, co upraszcza efekt. Na ST można było kosztem zmniejszenia wysokości dać duży obrazek.

Jestem za opcją 2.

Gdyby demo powstawało najpierw na Amigę, a potem na ST, to właśnie - dół to Amiga, a góra to ST. Gdyby było odwrotnie - demo na Amigę wyglądało by identycznie jak ST, czyli jak górny obrazek.

Dawaj nowinkę na AOL, tam lubimy takie przedsięwzięcia :)
Mi się bardzo podoba :)

Ty tak z buta zacząłeś w tym asemblerze?

Wpłacone na Emilkę.

http://www.atari.org.pl/forum/viewtopic.php?id=16788

x_angel - rzeczywiście, nie zrozumiałem. A z tym równoległym połączeniem uzwojeń to dam głowę, że przy różnicach rzędu 0.2-0.3V prądy wyrównawcze będą odgrywały znikomą rolę. Ale rozumiem, że tak się nie powinno robić. Aby to jednak sprawdzić pewnie wystarczy zewrzeć uzwojenia z jednej strony a następnie badać napięcie różnicowe z drugiej. Jeśli jest 0-0.1V to śmiało można łączyć równolegle. Czy to dobry tok rozumowania?

I have looked in, there is some work to do because code is macro-overloaded and care is needed.

And what lib is that You use in your firmwares?

Zawsze miałem problem z linią wywołań exomizera, więc nie wiem.

A co myślisz o tym:

ZX1 is a simpler but faster version of ZX0 that sacrifices about 1.5% compression to run about 15% faster.
https://github.com/einar-saukas/ZX1

W sumie jak jest zx0 to zx1 będzie łatwo. W sumie w grze niemal zawsze chodzi o szybkość, więc może warto.

conan spakowany exomizerem 2.0.6. Rozpakowuje się domyślnie od końca, czyli można ładować niemal w miejsce docelowe, kilka bajtów niżej i lecieć z dekompresją. Natomiast nie jest tak szybki jak zx5, a to jeden z najszybszych dekompresorów.

@tebe - to głównie xxl robi te dekompresory - więc najlepiej by było, gdyby on to zrobił, wtedy będzie w jednym miejscu i spójnie. Co z tego, że ktoś inny to zrobi, jak zniknie to w bezmiarach internetu.

-- digging out --
The problem is that there are 2 (fat16) or 4(fat32) bytes per sector. So in naive approach there is ~32 kb/4=8 000 frames to remember, which gives 160 seconds of uninterrupted video. Less naive approach is to remember only jumps to "not next" sectors with run length encoding of "next" sectors. Then it makes sense. But reading of 8kb by the CPU takes some time and processing of those 8 kb also, so I bet 1/2 of the second to one second is needed to process one fat sector. For 3-minutes movies it is acceptable to wait 2-3 seconds, but for full-length movies waiting for minute or two is too long. Of course, the time may be stripped down by clever programming, but the time needed to start playing will be annoying.