:( No faktycznie szkoda.

Ale zaraz, przecież płyta Falcona już jakieś dwa czy trzy lata temu była prawie odtworzona przez gościa o ksywie (piszę z pamięci, bez sprawdzania) npatomn (lub jakoś mocno podobnie)
Nie śledzę atari-forum jakoś od tamtego czasu, więc czy to się nie udało ukończyć? Bo z tego co pamiętam, to było prawie na "finiszu", nawet na ostatnim sztabie ten temat był poruszany, ale też chyba nikt go nie dokończył. Czy w takim razie projekt padł, wie ktoś?

W c i dość ciężkawej bibliotece SDL. Taka specyfika SDLowych rzeczy, że nic nie ruszy na gołym Falconie w zadawalającej prędkości.
Edit:
A drugim dość istotnie wpływającym czynnikiem na wydajność tego typu projektów, jest to, że są to projekty tworzone dość współcześnie (ta gra jest z dwa tysiące jedenastego) na platformę która ma mega-giga-herce i nikt z twórców za bardzo się nie przejmuje, że "jedzie" zbędnie po zasobach. Dla przykładu ta gra ma grafikę w plikach bmp o ośmiobitowej głębi kolorów, natomiast sam silnik graficzny jest inicjalizowany w 32bitach.
Z punktu widzenia platformy docelowej dla której ta gra była tworzona, takie coś nie ma najmniejszego znaczenia, natomiast chcąc ją uruchomić na Falconie, to po pierwsze potrzebna by była lepsza grafika (Super Videl czy Radeon) a po drugie "przerzucanie" takiej ilości pustych bitów po magistrali jednak dość mocno obciąża Falcona (nie wspominając, że jest bez sensu)
Wszystkie porty tej gry (a jest ich trochę) nie ruszały zupełnie silnika graficznego i działały właśnie w ten sposób. Natomiast na Falconie to nie miało zupełnie racji bytu, więc musiałem przerobić ten silnik na osiem bitów (co powinno być dość prostą operacją, ale "napsuło" mi dużo krwi, bo wszystko oprócz tła się przełączyło bez problemu a przełączenie tła zajęło mi gdzieś pewnie 80% czasu) co dało niesamowity skok wydajności.
Oczywiście dało by się na pewno zoptymalizować więcej rzeczy przerabiając je mniej lub bardziej.

No brakuje sinf, cosf, acosf, atanf i tak dalej. Wyczytałem wczoraj, że te funkcje "dotarły" do standardu nazwanego C99. Ale ich w "naszym" libm nie ma, są tylko podstawowe sin, cos i tak dalej.
Tyle, że w kodzie właśnie są tylko te podstawowe, to podczas kompilacji coś się dzieje, że są zamieniane na odpowiedniki "f" (których właśnie nie ma) Dlatego szukałem (bezowocnie) jakiejś opcji do dostarczenia kompilatorowi aby nie optymalizował sin na sinf, cos na cosf itp. Ale nic nie znalazłem.

Tego nie znałem, ale właśnie spróbowałem w jednym pliku źródłowym podmienić na math-68881.h (bo math-68882.h nie istnieje, przynajmniej w tym Thorsten'owym toolchain'ie) i po uruchomieniu make, przestał krzyczeć, że w dla pliku obiektowego tej źródłówki ma undefined reference! :)
Na razie nie mam czasu na dalsze działania, ale później spróbuję to zrobić we wszystkich źródłach używających math.h bo wygląda na to, że to da efekt jaki potrzebuję! (czyli zostawi w spokoju oryginalne wywołania, bez zamieniania ich podczas kompilacji na odpowiedniki "f")

Nie znam Elektrody, ale jeśli jest to miejsce gdzie wątki właśnie wyglądają jak ten tutaj przedstawiony, to również popieram protest, głównie w imię tego, aby z AA nie zrobiło się właśnie takie nic nie wnoszące wizualne niewiadomo co.

Dzieki za pomysły. Generalnie już wczoraj wieczorem użyłem na szybko to dd wg parametrów @mono i to co "wypluło" bez problemu otworzyło się w XnView! :)

AS, jesteś pewien, że to chcesz? Bo zawsze się odgrażasz, że linii STx to nigdy nie będziesz miał.

Nie tylko na telefonie jest nieklikalny

Mniam

Zapowiada się wyśmienicie, choć do oryginału jeszcze daleko. Ale oby się udało, bo choć obenie nie gram specjalnie jakoś w tego typu gry, to w tą chętnie bym pograł, bo w owych czasach tęsknie spoglądałem na tą grę :)