Polemizował bym z tą "natywnością" ;) Ale faktem jest, że na PC nie spotkałem się nigdy z tak wygodnymi klawiaturami jak na Atari i po prostu lubię pisać na Atari. A że robię to głównie w TB XL - nie mam z tym problemu... Choć część rzeczy i tak jestem zmuszony na PC (np. grafika, gdyż nie mam niestety grafików chętnych do współpracy). ale PC to PC - narzędzie tylko.

Są bugi, bo to preview na zlot. Przejść nie można i fabuły też nie ma, ale pochodzić i postrzelać można. Walka ze stworkami z formalnego punktu widzenia wyczerpuje znamiona gry ;)

Sikorze, po tym sformułowaniu ten wątek trzeba byłoby zamknąć, bo nic sobie nie robisz z wypowiedzi jakie tu padają i pogrążasz się w swoim radykalizmie. Przeoczyłeś chyba kilka stron dyskusji, w których ludzie próbowali argumentować, że to co C64 ma za darmo w Atari trzeba smarować pamięcią i nie inaczej jest we Flimbo's Quest.
C64 ma 256 znaków w generatorze, co pozwala im na uzyskanie paralaksy dosłownie za darmo. Wszystko mieści im się w 4 generatorach, które przełączana się na zmianę w kolejnych fazach paralaksy. 8kB i z bani.
Z drugiej strony Atari ma 128 znaków w generatorze i brak sprajtów, które również muszą być wpisywane w fonty, co dodatkowo zmniejsza nam liczbę wolnych znaków na tilesy. W rezultacie, żeby uzyskać sam background, który w C64 zajął, przypominam, 8192 bajty ja potrzebowałem 13 generatorów żeby objąć nimi cały ekran + 64 kB w bankach, żeby pomiędzy ruchami postaci streamować dane fontów dla tilesów które mają się za chwilę pojawić. A to dopiero background i nawet nie doszliśmy do obsługi soft sprajtów. I przypominam, że wszystko chodzi w takim samym tempie 50 fps jak na C64.

I za takie coś dostaję w twarz tekstem:

Wstydź się Sikorze, bo takimi tekstami tylko zniechęcasz ludzi do ciężkiej pracy i poświęcania swojego (cennego, bo mamy rodziny i dzieci) czasu na Atari.

@grzybson - musi mieć na już, jeżeli chcemy mieć 50 fps, ale z formalnego punktu widzenia, jeżeli zadowolimy się, powiedzmy, 0.1 fps, to mogę co klatkę animacji czytać kilka kilobajtów z dyskietki i wtedy ruszy na stocku i nawet bez carta ;)

@laoo/ng, szanuję Was i pewnych rzeczy na pewno nie da się przeskoczyć, choć na wspomnianym ZX SPECTRUM które ma 48Kb pamięci RAM i brak trybu tekstowego (o ile kojarzę) da radę robić rozbudowane rzeczy, a u nas - niestety - słyszę tylko "nie da się". Skoro ruszanie się postacią i zbieranie przedmiotów już nazywasz grą (wymagającą tyle pamięci, ile wymaga) to przepraszam, ale chyba mamy inną definicję gry... Tym bardziej, że o ile się nie mylę - brała udział w konkursie.
Mimo wszystko trzymam kciuki za powodzenie projektu, choć z drugiej strony bardzo mi przykro, że posiadacze nierozbudowanego Atari nawet nie usiądą koło tej gry :/ Zasadniczo to i tak wybór autora, na czym pójdzie, więc to dyskusja czysto akademicka. Mnie osobiście sam gameplay w FQ nie pociąga, ale ja już tak mam. Technicznie widać, że masę pracy należy (kiedyś) w to włożyć.

Qr... Sam sobie szkodzę, że tu jeszcze wchodzę :]

@Sikor - z całym szacunkiem - Ty chyba więcej piszesz na forach niż je czytasz, panowie celują w 1MB carta więc gracze nierozbudowanego Atari usiądą przy tej grze :P

Oczywiście o ile tylko dożyją.

@laoo: piękna perspektywa:-) W końcu bez maseczek:-) Tylko nie widzę, żeby razem z nami na tym zdjęciu przetrwało jeszcze jakieś Atari:-)

nie jest szbszy. ma jedna ceche wykorzystywana podczas scrolla ktora faktycznie dziala duzo sprawniej na z80 ale ... ale... atari ma sprzetowy scroll i to co zx robi naprawde bardzo sprawnie ale jednak zajmuje trohe czasu to atari robi w kilku cyklach ;-)

1. gra posiada caly gameplay jaki posiada oryginalna gra - z ta roznica, ze w wersji pokazanej posiadala tylko 2 levele. tam nie ma wiecej gameplayu. technicznie jakby byly gotowe assety reszty leveli i przeciwnikow - gra odpalila by wszystkie 7 plansz.

2. gra bedzie dzialac na stock atari 64kb (kartridz), wiec nie wiem o czym piszesz.

3. u mnie w repozytorium lezy od dluzszego czasu wersja z poprawionymi wszystkimi bugami, nie wywalajaca sie, wyswietlajaca ~tyle przeciwnikow co c64 (czyli 4-5 duzych przeciwnikow + gracz) - wszystko dalej 50fps.

gra bedzie przechodzila niebawem ostatni (juz trzeci - lol) refactor pod nasz nowy wewnetrzny SDK, m.in. po to aby dzialala na atari 64kb z kartridza i aby troche posprzatac rushowany kod w kilku miejscach. Na commodore gra tez byla na kartridzu i rowniez zajmuje SPORO pamieci (na kartridzu). Wersja dyskowa to crackniety rip (z crunchowaniem danych).

niewyobrazasz sobie ile tutaj trzeba bylo dosc skomplikowanych rzeczy zrobic, aby ta gra byla mozliwa na naszym Atari. Zreszta kazdy wiedzial, ze tego sie nie da. Zastosowalismy streamowanie danych (tak jak w obecnym gamedevie) od fontow po uklad ascii levelu jest tam robiony co kazda ramke - cząstki danych sa streamowane w zaleznosci czy gracz idzie w lewo czy w prawo - tam nie jest jest "tylko scroll" bo za ekranem po obu stronach sa smieci. Wszystko jest nonstop streamowane z lewej/prawej strony ekranu.

jest duza szansa, ze w tym roku gra wyjdzie jako full. 3 miesiace po SV mialem z grubsza wszystko popoprawiane w kodzie, ale stwierdzilismy, ze projekt poczeka - aby go przerzucic na nasz nowy SDK, bo moga jakies problemy pod koniec wyjsc (zwiazane z kartridzem i rzezbieniem tego recznie). Grubo sie zastanowimy, czy jest sens tak robienia tak ciezkich projektow. laoo'wi w pewnym momencie sie na chwile nie chcialo, czytuajac to bzesensowne i niezasadnione marudzenie. przypominam, ze nasza grupa zawsze konczy swoje projekty, nie mamy zadnego nieskonczonego  (@W sie nie liczy!;) - zarowno FQ jak i MK jest dalej na tapecie i beda dowiezione. ale c*** tam.

Sorry, że odbiegnę od tematu trochę, ale interesują mnie technikalia. @solo, co daje w praktyce streamowanie danych i generowanie ich w prawo i lewo zamiast trzymania całej mapy w pamięci? Jaką szerokość (ile znaków) mają mapy we FQ?

@Mq Plansza FQ ma 10 ekranów, czyli 400 znaków w poziomie. Rozpatrując nawet pojedyncze wiersze, to przez te 400 znaków często wypada więcej niż 128 różnych, więc nie jest możliwe żeby dla każdego wiersza był statyczny generator, trzeba zatem zawartość generatora uaktualniać w trakcie przemieszczania się po planszy, żeby znalazło się tam to co ma być na ekranie (a dokładniej z pewnym wyprzedzeniem). Pamięć nie jest z gumy i nie można trzymać tych wszystkich danych (łącznie z informacjami jaka powinna być zawartość generatora dla danej pozycji na planszy) w podstawowym RAMie, dlatego trzymane jest to w bankach i przekopiowywane on-line w trakcie ruchu.  W wersji z party algorytm obliczający co ma być skopiowane jest zabugowany co objawia się miganiem tilesów na skrajnych prawych ekranach pierwszego levelu - można wtedy zobaczyć kiedy następuje te kopiowanie - w praktyce za późno, bo zdąży się wyświetlić jeszcze stara nie uaktualniona zawartość znaku.

@Jacques: Technicznie grę planuję na MegaCart 1 MB oraz zamiennie na 1 MB bankowanego PORTB, bo różnica jest trywialna - gdy ma się banki cartridga, to użycie banków RAMu to tylko adresowanie innego obsaru. Gorzej w drugą stronę - dlatego gra stanęła, bo robiliśmy automodyfikacje danych w bankach, czego nie da się zrobić z ROMem cartridge'a.

Uuu panie, to teraz rozumiem jakie to trudne i ile pamięci potrzeba. Bo tak sobie myślałem, ja akurat w swojej grze też robię takie scrollowane mapy, ale rysuję grafikę oszczędnie tak, żeby nie trzeba było podmieniać aż tak dużo znaków. I lepiej mi się opłaca trzymać na raz całą mapę wypakowaną i tylko sobie ją scrolluję. Do tego rysuję grafikę tak oszczędnie, żeby jednym zestawem znaków rysowała się aż cała mapa. Tylko że ja sobie sam tą grafikę rysuję, więc jak mam jakiś podobny znak, to trochę tam coś zawsze zmienię, żeby wykorzystać istniejący, a nie tworzyć i zajmować kolejnego. No ale tak się można bawić jak się tworzy nową grafikę, a Wy musicie przerysować istniejącą, więc ile jest znaków tyle musi być. W takim kontekście, to faktycznie zmieszczenie tego w małej ilości RAM-u nie jest możliwe. Czyli jeszcze w temacie wątku trzeba by rozdzielić kwestię tworzenia nowych autorskich gier na Atari, a kwestię portowania gier z innych platform, których teoretycznie nie powinno się dać przeportować, a jednak się da.