Taka ocena że to że demo powstało w 5 dni jest mocno niesprawidliwa , bo to że sama produkcja owszem została poskładana w niecały tydzień to nie oznacza że np mój kod z unified nie był rozbudowany czy nie siedziałem nad nim w wolnych chwilach żeby np móc robić wieloobiektową animację - np osobny obiekt głowa a osobny tułów co nieco przypomina uproszczoną animację szkieletową. Wiadomo że wykorzystaliśmy pewne rzeczy które już mieliśmy, ale to że zostały poskładane w 5 dni nie oznacza że sam kod nie był wcześniej rozwijany ;)  Nad silnikiem do Unified siedziałem od czasu Rewinda więc pół roku , został praktycznie od nowa napisany bazując na silniku z Reditusa
Co do gustów to właśnie po to rzuciłem luźne pytanie żeby je poznać ;)

Skoro tu jest taki temat , to zapytam wprost po ostatnim Foreverze - czego oczekuje demoscena ? Bo poza wzięciem pod uwagę miejsca party (Słowację gdzie już raz wygrał Joźnin z bazin) oraz ekipę (większość słowaków oraz inne platformy głosujące na demo "swoich") , doszły mnie głosy że demo słowaków było zabawne oraz świeże ;)
Zatem ponieważ mam dysonans poznawczy z tym co mi się wydawało : że demo ma być techniczną produkcją a oczekiwania ludzi - typu zabawne 2 czajniki na spritach śpiewające coś po czesku ...
Może ktoś mnie oświeci i podpowie w jakim kiedunku powinny iśc prace i czy czekujecie dema typu "Rewind" czy zabawę dla gawiedzi pokroju śpiewających spritów ?

Łącząc oba w/w posty to takie rzeczy powinien właśnie ustalać regulamin compo - to organizator powinien przyjąć pewien kompromis w tym co wolno a co nie i w której kategorii. Nie spotkałem się z publicznym ostracyzmem tego że np prace są wysyłane mailem czy przekazywane na nowych nośnikach typu pendrive a nie dyskietkach 5,25 czy kasetach magnetofonowych (swoją drogą nie wyobrażam sobie compo gdzie np demo wczytuje się z kasety magnetofonowej przez 90 minut a zawsze mogliby się znaleźć puryści którzy by chcieli taką formę ładowania danych)

Z pierwszą tezą się zgodzę - są różne 2 podejścia do tematu i nie da się tego pogodzić w żaden sposób.

Zastanawia mnie tylko sens robienia komuś pod górkę pisząc tak program żeby celowo nie działał na pewnych rozszerzonych urządzeniach - w tym przypadku to jest działanie złośliwe , mimo że teoretycznie z punktu softu jak i sprzętu działa na oryginalnych atarkach.

Oczywiście jeśli to miałoby mieć jakiś techniczny sens to jeszcze zrozumiem, natomiast moim zdaniem jest zwykłym sk****ństwem pisanie softu tak żeby komuś celowo nie działał w pewnych konfiguracjach.

Co do nielegali jeszcze jedno - procesory do Atari produkowało kilku producentów i wystarczy że któryś używał innej maski i nie musi to działać poprawnie - pamiętam że było kiedyś jakieś demo , które nie działało u wszystkich ....

jak sam napisałeś:

"ci ktorzy tworza oprogrgamowanie wytyczaja kierunki a nie ci ktorzy tworza regulaminy..."

Regulaminy są podobnie jak przepisy ruchu drogowego po żeby wszyscy użytkownicy byli poszanowani ... Żeby nie znalazł się jakiś purysta który kupi samochód "anglika" uznając że będzie jeździł pod prąd ponieważ dla niego naturalnym jest ruch lewostronny...

Pin - pisałem kilka postów wyżej - taki cart działający na zwykłej gołej 65 może mieć w środku poza 1mb ramu jeszcze jakiś raspberry pi i co wtedy ?

Ja się wypowiem ze swojej strony , uważam że stosowanie tzw nielegali ma sens w przypadku pracy na totalnie seryjne atari z 64kb ramu , jako powiedzmy że osobna kategoria dema - dla typowych purystów. Z mojej strony używanie rozszerzeń pamięci pozwala na napisanie dużo lepszych efektów i wręcz nieraz niemożliwych do uzyskania na gołych 64k i choćby nie wiadomo ile nielegali było ...  Prosty przykład DOOMa z dema Rewind - wymaga tak naprawdę 3 banków czyli standardowego 130xe i to w zasadzie do samej grafiki ;) To że samo demo wymaga 1MB wynika z ilości grafiki animacji oraz braku czasu żeby to upchać do mniejszej ilości pamięci.
Natomiast jeśli się zgadzamy na używanie większej ilości pamięci to w dobrym tonie jest nieużywanie nielagali, choćby ze względu na to że pozwoli to na oglądnięcie pracy większej ilości ludzi a w końcu jak siedzę nad jakimś efektem czy demem kilka miesięcy to  po to żeby zapewnić rozrywkę jak największej ilości użytkowników. Stąd moje mieszane uczucia były przy wymaganiu 1MB ramu.
Oczywiście nie wyobrażam sobie konkurowania dema z rapidusem i vbxe w jednej kategorii z czystym sprzętem z ew rozszerzeniem pamięci.
Tego typu problemów zapewne można by było wyszukać dużo więcej - np demo na cartridge i teraz ile może zajmować ROMu cartridga , czy stosowanie dodatkowych koprocesorów wewnątrz cartridge jest legalne jeśli chodzi to na seryjnym Atari a wkładamy sam cartridge ?

Ja również dziękuję ,za namową chłopaków z NG fajnie było się spotkać po 17 latach oraz poznać na żywo kilka osób :)

Panowie ale o jakim raycasterze piszecie ???????? Doom nie jest raycasterem tylko enginem wyświetlający świat zdefiniowany jako 2d w 3d ale z użyciem linii a nie kwadratów jako ścian - stąd ma możliwość używania ścian pod dowlonym kątem ....
Co do okna wyświetlania to też jest ciekawe bo algorytm dooma używa wielokątów wypukłych do definiowania sektorów - zawsze gracz jest wewnątrz jakiegoś wielokąta i przy użyciu niewidzialnych lini bądź bram renderuje pozostałe sektory więc okno wyświetlania się zawęża w miarę jak zostanie wygenerowany pierwszy plan, jedyne co ma wspólnego z raycasterem to iteracja między scianą a obserwatorem i kątem widzenia - po prostu sprawdza każdą ze ścian i renderuje tylko widoczną część.
Zatem sama szybkość texturowania nie ma aż takiego znaczenia ponieważ tutaj poza obiektami przeźroczystymi renderuje tylko jedną linie w obszarze widzenia - używa do tego z-bufora i jeśli coś na danej pozycji zostało wyświetlone to poza spritami ignoruje to miejsce przy rysowaniu ścian. bardzo zagmatwany algorytm , siedzę nad nim już ponad tydzień za to widać że da się jeszcze trochę urwać na szybkości ;)
Teoretycznie gdyby dało się uzyskać 2x więcej pixeli poziomo to w pionie mógłbym używać trybu 2 pixelowego i wtedy mając kwadratowe pixele mam 4 x większe okno widzenia

Tylko że ta gra to port raycastrera z uproszczonym texturowaniem itp , tutaj jest część silnika dooma skompilowana pod 6502 i częściowo przepisana w asmie.
Porównywanie tych 2 technologi to jak porównanie Atari XE do Atari ST - doom to inna liga - ściany pod różnymi kątami , duża ilość spritów itp.

Na razie chciałbym sprawdzić na ile da się to odpalić na Atari oraz jak to będzie działało - czy jest sens próbować coś przy tym grzebać. W zasadzie mając silnik XXL, mój nowy silnik do dema napisany na bazie silnika dema Maze oraz VicDooma , który ma ogarniętą najgorszą część enginu - czyli jest grywalny - ogarnia logikę potworów, gracza, kolizje itp można spróbować połączyć siły i zrobić coś naprawdę sensownego ;)

XXL widzę że engine już całkiem fajnie chodzi.
Ja podjąłem rękawicę i odpaliłem tego VICDOOMA na Atari , na razie to wersja mocno prebeta , tylko w celu testowym - zrzut pamięci z VIC20 , dołożona display lista, zmodyfikowane skoki oraz zrzut rejestrów i skok do zamrożonego ramu.

Nie wiem pod jakim kątem piszesz swój engine , ja chciałbym zrobić jakieś małe demo na moim a nie nadaje się to zbytnio do zrobienia gry , za to chętnie mogę pomóc w czymś w co można by było pograć ;)

Wysłałem Ci pw z kawałkami kodu oraz pewnymi koncepcjami.

W odpowiedzi do Laoo
często zapisuję ułamki właśnie jako n/256 i zamiast dzielić mnożę przez n/256 ;) to ma zaletę że starszy bajt po mnożeniu stanowi wartość całkowitą a młodszy ułamek , w moim ECU zbudowanym na 65c816 mnożę x*y/100 - jako że jedna z wartości jest w % więc dla zwiększenia precyzji używam (u/256*x+y*x)/100 , potem resztę z mnożenia n/100 zamieniam na n/256.
Po przemnożeniu x*u/256 - starszy bajt jest wartością całkowitą , młodszy częścią ułamkową. Na podobnej zasadzie odtwarzam sample:

lda ulamekCnt
adc ulamek
sta ulamekCnt

lda pozycja_fali
adc step
sta pozycja_fali