Czytając teraz wszystkie wypowiedzi zauważyłem dziwną zgodność swoich poglądów z Macgyverem, frasunek!
Music compo: zlikwidować "jeśli organizator wyrazi zgodę", dopuścić RMT i COMy.
Gfx compo: jedno. Czekam na odpowiedź Vasca na to, co pisałem w Syzygy, również ostatnio. Rozumiem, że gdy pojawi się konwerter np. PNG->MIC/GR8/INP/INT/CIN
(kwestia kilku minut), formaty te zostaną dopuszczone do Conversion Gfx compo. Oczywiście, PNG dopiero po wypuszczeniu przeglądarki PNG (to już troszkę więcej roboty). Albo wiem - chodzi o to, żeby taki konwerter trzymać w tajemnicy - wtedy będziemy wystawiać na Graphics compo, bo przecież Conversion Gfx compo ich nie dopuszcza. Proszę jeszcze raz zastanowić się nad sensem wymieniania formatów graficznych, szczególnie takich, które można łatwo skonwertować, jak np. MIC<>PIC czy GR8<>CPR.
Mikey: problem TIPa nie polega na braku narzędzi do rysowania na Atari, gdzie mamy tłum dobrych grafików. Problem polega na tym, że brakuje grafików potrafiących specjalnie przygotować obrazek wykorzystujący ten tryb.
Intro 256: wracanie do DOSu to bzdura. Nigdy tego nie było, a oznaczałoby stratę wielu cennych bajtów. Ewentualnie można napisać, żeby komp nadawał się do użytku po resecie. Zasadniczo jestem też przeciwny nieliczeniu nagłówków, ale ponieważ sam kiedyś z tego skorzystałem, ostatecznie to przeboleję. Trzeba sprecyzować, czy intro może się wczytywać na stos i/lub stronę zerową i czy może korzystać z tego, że pamięć jest wyzerowana (były z tymi sprawami problemy).
Intra&demo: zakaz używania nielegalnych rozkazów jest zły. Jeśli są to dlaczego ich nie wykorzystać? Np. efekt działa o ramkę szybciej jeśli mamy stare 6502 (czyli na XL i starych XE). Oczywiście program sam musi to wykryć i radzić sobie jakoś, jeśli nielegalnych rozkazów nie ma. Ogólnie nie widzę sensu wymieniania akurat nielegalnych rozkazów 6502, skoro nie ma mowy o 65CE02, 65816 i innych prockach. Moje zdanie jest takie: umiem wykryć dodatkowe możliwości i wykorzystać je - ok. Wymagam konkretnego rodzaju procka - źle.
"ze wszystkimi możliwymi 64 lub 128 bankami do wyboru" - to może być mocno niezrozumiałe. 128 banków ma rozszerzenie +2MB i teraz trzeba się zastanowić, czy domagać się możliwości wyboru dowolnych banków dostępnych w tym rozszerzeniu.
Wiąże się to z pewnym dodatkowym nakładem pracy i wydaje mi się, że jest to wciąż "wiedza tajemna".
Loadery: nie mam nic przeciwko nim, o ile są opcjonalne. Generalnie po to jest dodatkowa pamięć, żeby wczytać wszystko naraz. Jeśli ktoś chce napisać demo z efektami przy transmisji szeregowej, działające na 64 KB - proszę bardzo (chętnie bym zobaczył Overmind II), ale niech będzie możliwość wczytania z twardziela do pamięci 1 MB i wtedy efekty mogą być, gdy dane przepisują się z dodatkowej pamięci.
Gęstość medium: ok, wbrew pozorom niektórzy mają nieprzerobione 1050 (nie tyle w Polsce, co gdzie indziej).
Co do dem plikowych - generalnie dobry pomysł, ale tylko dla dem, które mieszczą się na jednej stronie medium.
"Jeśli demo posiada efekty podczas ładowania, nie może używać RAMu pod obszarem FPP - gdyż musi ruszać z HDD." - źle sformułowane - tak, jakby nie można użyć RAMu $d800-$dfff po wczytaniu dema. Chodzi o to, że sterownik SIO może się znajdować w tym obszarze i nie należy oczekiwać, że procedura SIO wczyta nam coś do tego obszaru. Ponieważ SIO jest w ROMie, to nie widzę większego sensu dla tego punktu, chyba że ktoś kopiuje OS do RAMu, a później robi JSR $e459, żeby wczytać w obszar FP - zwolennicy używania DOSów do wczytywania dem niech się wypowiedzą, czy można wczytywać dane bezpośrednio do pamięci pod ROMem i/lub rozszerzonej.