Sikor: doprawdy, nie za bardzo kumam twoja argumentacje - imho jest lekko pozbawiona logiki... hmm.. chyba ze.. MAM ! jest to zabieg celowy ! Wprowadzasz zamet, zeby ludzie tygodniami glowkowali i doszukiwali sie sensu tam gdzie go nie ma, a tymczasem to tylko odwrocenie uwagi, bo ty cichaczem skladasz demko na 65816 :))) Ach... rozgryzlem Cie ;) Ale nie martw sie, nikomu o tym nie powiem ;)

Messiah: Widac przygoda ze scena atarowska tak samo szybko sie konczy jak sie zaczela ;) A szkoda, bo slyszalem z przeciekow, ze na LP2k3 ma byc jedna produkcja poswiecona Tobie ;)

Lisu: ja bym na twoim miejscu sprecyzowal co chcesz miec w tej atarce - bo z tego co wiem nadworni elektronicy raczej nie przyjezdzaja z wielkim asortymentem i raczej nalezy z nimi ustalic wczesniej to co chce sie zainstalowac w swojej maszynce.

Zastanawiam sie, jak mialyby wypasc w praktyce rozdzielone konkursy - zalozmy, ze 2 prace pojawia sie na jednym i 2 na drugim... Ktos juz wczesniej wspomnial, ze gdyby w jednym i drugim przypadku bylo po kilkanascie prac, to mozna sie w takie podzialy bawic. Oby tylko liczba konkursow nagle nie okazala sie wieksza od liczby prac na nich wystawianych :P

Rozumiem, ze ostateczna decyzja i tak nalezy do Vasco. No, ale moze warto sie zasugerowac opnia mas (ankieta z topica Pikselizacja v$ Konwersja) czy tez opiniami grafikow, ktorzy jak na razie mimo stosowania roznych technik (stojac niejako po roznych stronach barykady) do tej pory byli jednak zwolennikami jednego konkursu graficznego.
Proponuje, aby na temat czy rozdzielac konkursy wypowiedzieli sie inni czolowi graficy, np. Anj, Replay - zdanie Dracona, Vidola i Tigera juz znamy.

Mikey: no twoje zdanie juz znam - ale dlaczego uwazasz, ze powinny byc oddzielne konkursy graficzne ? Jakie argumenty za tym przemawiaja ?

A co na przyklad z sytuacjami, gdzie np. czesc pracy powstala na PC, czesc na Atari - gdzie kwalifikowac takie prace ?

Co do oddzielnego Covox Compo i Pokey Compo rozumiem. Powiedzmy inna technika generowania dzwieku, inne urzadzenie koncowe itp. Ale prace graficzne sa wyswietlane za pomoca tych samych ukladow graficznych: ANTIC + GTIA.

Toczyla sie juz jakis czas temu dyskusja na Ring-u Pikselizacja vs Konwersja. Z ankiety wynikalo jasno, ze wiekszosc ludzi ocenia efekt koncowy, a nie narzedzie. Wypowiedzie grafikow tez tam widnieja - dobrym przykladem jest np. wypowiedz Tiger-a: on sam nalezy do grafikow pixlujacych, ale jest zwolennikiem aby istnialo jedno compo graficzne. To samo dotyczy Dracon-a, ktory stoi po drugiej stronie barykady. Zatem, czy warto na sile cos rozdzielac ?

Mi osobiscie regulamin Vasca odpowiada, chociaz pare rzeczy bym zmienil i dodal jeden punkt ogolny:

1.Intro 256b - IMHO zmienilbym przepis, ze intro musi wracac do DOS-u - wydaje mi sie, ze istota pracy 256b jest efekt sam w sobie wycisniety w 256b a nie koncentrowanie sie na obsludze systemu - ktos moglby powiedziec - jeden RTS lub JMP (xx) nie jest problemem, jednak zwrocmy uwage na taki przypadek: zalozmy ze jest pojedynczy efekt, ktory jest zapetlony np. jednym JMP - teraz, aby wyjsc do DOS-u potrzeba np. zrobic dodatkowa petle czasowa, co pociaga za soba dodatkowe bajty, a wiadomo, ze w pracy 256b licza sie czesto wlasnie pojedyncze bajty.
Wydaje mi sie, ze moznabyloby wyjatkowo 256b przerywac resetem.

2.Intro 16k i wybor reczny bankow - nie zapominajmy, ze napisanie chocby najbardziej prymitywnego interfejsu uzytkownika, umozliwiajacego wybor bankow tez pociaga za soba "urzniecie" pliku intra o kawalek, ktory mozna wykorzystac np. na kod samego intra - dlatego proponuje aby przyjac zasade: dozwolone sztywne uzycie bankow: C3,C7,CB,CF - przy tych kombinacjach zarowno RAMBO jak i COMPY SHOP beda sie zachowywac identycznie, czyli nie bedzie niezaleznego dostepu ANTIC-a i CPU. Wlasnie z racji ograniczenia proponuje ulatwic zycie koderow.

3.(to moze wywolac burze) nie robic dwoch oddzielnych Gfx Compo - z tym, ze np. w wypadku, gdy praca wyglada na konwersje zarzadac od grafika kilku wczesniejszych kopii roboczych. Wydaje mi sie, ze ludnosc na party potrafi docenic prace grafika, przeciez wiadomo, ze nie wystarczy zrobic byle szajsu pod "fotosklepem" i skonwertowac tego na Atari, zeby to dobrze wygladalo na "maluchu" - poza tym co wtedy, gdy np. praca zostala czesciowo zrobiona na PC (np. szkic), a potem dopikslowana na Atari ? Zreszta tzw. chamskie konwersje mozna odrzucic - przeciez kazdy chyba potrafi dostrzec grafike rysowana w wyzszej rozdzielczosci i konwertowana np. na HIP-a wyraznie wtedy mozna dostrzec utrate wyrazistosci obrazka, duze rozmycie, utrate szczegolowosci - sa graficy, ktorzy nie odwalaja takiej tandety i ich prace naprawde dobrze wygladaja na Atari, bo pod katem Atari byly rysowane a nie pod katem PC.

4.Do ogolnych zasad dolaczyc punkt: praca w momencie dostarczenia na
compo zostaje rozpowszechniona w takiej samej postaci zaraz po compo, takze nie ma miejsca, ze ktos dostarcza demo, mowiac ze jest niedokonczone i prosi, zeby nie rozpuszczac demka, bo pare dni po party dokonczy i wypusci pelna produkcje - nie jest nigdzie powiedziane, ze produkacja wystawiana musi byc dokonczona, ale warunkiem dopuszczenia do compo niech bedzie automatyczna zgoda na "wypuszczenie w swiat" w takiej postaci, w jakiej zostala dostraczona na compo.

Aha... i z ostatniej chwili - przypomnialo mi sie:

5.Zabronic uzywania nielegalnych rozkazow 6502, ale wymagac, zeby demo dzialalo poprawnie na 6502. Nielegalne rozkazy 6502 wykluczaja uruchomienie produkcji na 6502C i 65816, stad zakaz, z drugiej jednak strony 65816 poki co nie jest standardem na scenie (mozliwe, ze niedlugo bedzie) wiec trzeba pamietac, ze 6502 to jest mimo wszystko podstawa. Nie mozna tez wymagac od koderow, zeby ich demo pisane pod 6502 dzialalo na 65816, gdyz po prostu wiekszosc z nich nie ma mozliwosci przetestowania produkcji na 65816, a eliminacja nielegalnych rozkazow powinna byc wlasciwym krokiem w kierunku zgodnosci.

Amen. Czekam na burze ;)

Pozwolilem sobie obejrzec te demka, do ktorych linki tutaj padly.  Przez przypadek znalazlem Defloration by Fraction i w sumie bylo zdecydowanie ciekawsze niz te tutaj wymienione. Szczerze mowiac nie przepadam za produkcjami z jakimis zakreconymi klimatami - moze ktos rzucic tytulami demek gdzie mozna ujrzec efekty typu wektorowka, tunele, bumpy etc ?

Chyba sie nie zrozumielismy. Chodzi o to, ze funkcja numer 39 i 40 w CIO ma mozliwosc ladowania plikow binarnych/wykonywalych (odpowiednik Basicowego XIO) i nie ma problemu, zebym za pomoca kodu na pierwszej stronie dysku zaladowal plik z drugiej strony dysku za pomoca D: a nie D1: - wystarczy, ze wykryje czy plik z drugiej strony dysku jest dostepny w obrebie bierzacego katalogu (D:*.*) jezeli tak, to po prostu za pomoca tej fukcji wczytam go, jezeli nie, to wyswietle napis "wrzuc synku strone B" i wydaje mi sie, ze nie byloby to problemem - problem widze w czyms innym - funkcje numer 39/40 suportuja napewno MyDOS i SpartaDOS, bardziej prymitywne DOS-y nie.
I do tego wlasnie odwoluje sie moje pytanie - czy moga uzyc tej funkcji, czy mam pisac wlasny system ladowania plikow binarnych ?

Vasco: Odnosnie Intra wracajacego do DOS-a (tudziez innego nadrzednego loadera) jestem za !

Mam tez pytanie odnosnie regulaminu w demo compo -
jak wyglada ograniczenie odnosnie dlugosci pliku/plikow w demo compo ? max. 2 strony dysku Enhanced czy Double ?

Czy moze byc to jeden dlugi plik, nie przekraczajacy w sumie dlugoscia dwoch stron ?

Czy druga strona moze doczytywac sie za pomoca komendy do ladowania binow (XIO), ktora napewno posiadaja MyDOS i SpartaDOS (inne niestety nie z tego co wiem) ?

W wersji Trial nie bylo takiej mozliwosci niestety (najnowsze APE pod Windows)

Motorola 68000 jest w stanie zaadresowac 16 MB (24 bity), z czego w wypadku Atari ST(e) (rowniez Falcon-a i TT) obszar dwoch ostatnich megabajtow ($e00000-$ffffff) jest wykorzystywany przez rejestry sprzetowe, ROM itp, stad rozszerzenia pamieci 14 MB a nie 16 MB.

TT RAM (czyli Fast RAM w pojeciu duzo-atarowskim) jest adresowany powyze 16 MB, czyli w wypadku procesora MC 68k nie wchodzi w rachube - MC68030 ma 32-bitowa szyne adresowa, stad mozliwosc wrzucenia RAM-u powyzej 16 MB w Atari TT. Z Falconem jest niestety gorzej, bo wprawdzie siedzi tam 030, ale i tak tylko 24 linie adresowe sa wyprowadzone na plyte. Nie wiem, czy jest mozliwosc zainstalowania TT RAM-u na Falconie ze standardowym CPU - oczywiscie karty turbo gdzie siedzi drugi (szybszy) procesor maja sloty na TT RAM (CT60 umozliwia wrzucenie nawet 512 MB).

Foxiu, nie uwzgledniles tych, ktorzy koduja w ASCII i w hexach ;)

A powaznie - wychowalem sie na QA i do sierpnia tego roku robilem wszystko praktycznie pod nim. MAC65 jakos nigdy nie podchodzil mi (moze ze wzgledu na edytor). Obecnie wszystko robie w Qasm-ie - traktuje go jako QA z duzo wiekszym buforem i szybszym kompilatorem (nawet czcionki i kolorowy w edytorze sa praktycznie takie same) - rzeklbym, ze to kwestia przyzwyczajenia.

Co do Xasm-a - jestem juz starym czlowiekiem, wiec niechetnie zmieniam przyzwyczajenia. Byc moze, gdyby nie ukazal sie Qasm, to pracowalbym pod Xasm-em, z racji tego, ze po latach ograniczenia QA staja sie uciazliwe - az sie dziwie, ze to co stworzylem do tej pory robilem na QA - tysiace linii, laczenie zrodel... wtedy to sie mialo zapal ;)

Lewis: tez bym wolal, gdyby nie ograniczenia w wielkosci bufora QA :/