1

(8 odpowiedzi, napisanych Scena - 8bit)

co do mista to ma jakiś bug przy emulacji 1mb , tak samo nie chce działać rewind 1 a niektóre dema jak np unified syfią - tak jakby coś było nie tak z obsługą banków i o ile tam siedzi grafika to jest syf a jak już kod to się krzaczy.
Co do w1k - pisałeś że z fujinetu działa - czy na tym samym sprzęcie tylko w innej konfiguracji Ci nie odpala ?

2

(893 odpowiedzi, napisanych Scena - 8bit)

seabrush może byś się kiedyś pojawił w końcu na jakimś party bo Cię nie widziałem z 20 lat ... chyba od któregoś quasta

3

(80 odpowiedzi, napisanych Zloty)

dzięki wszystkim za docenienie wkładu pracy przy "matrixie" kodu do rewinda 2 ;) zajebiście to człowieka motywuje , przy okazji fajnie był spotkać (nieraz po wielu latach) znajomych oraz poznać jak zawsze trochę nowych osób :)

4

(893 odpowiedzi, napisanych Scena - 8bit)

Jeśli juz o to chodzi to, jak słusznie ktoś napisał na priv - że tam to by i Numen i Numen 2 przegrał z Zvonkami ;)
TEBE - nie chodzi żeby wygrywać zawsze ,gdybyśmy przegrali na Loście z Agendą to nie miałbym do nikogo pretensji - po prostu demo z pieskiem by się bardziej podobało (bo graficznie było świetne)  i nie miałbym poczucia że wyniki są że tak powiem średnio obiektywne.
Tutaj mam delikatne wątpliwości czy głosowanie nie było lekko z dupy więc chciałem trochę wysondować jaka jest opinia ludzi w tym temacie.
Jak Solo napisał ja też nie będę nic robił na Forevera bo tam krecik jeżdżący na robocie rumba i krzyczący "ja sem neteperek" miałby większe szanse niż nasze demo ;)

5

(893 odpowiedzi, napisanych Scena - 8bit)

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ć ;)

6

(893 odpowiedzi, napisanych Scena - 8bit)

gdzie wy tam mieliście włączony ekran ? ja tam widzę włączone sprity przy wyłaczonym ekranie żeby mało czasu dma zabierało i tyle ;)  Ponieważ każdemu się coś innego może podobać więc zapytałem na forum jakie są opinie ludzi i w ten sposób można wyciągnąć jakieś wnioski na przyszłość co do sensowności spuszczania się nad kodem i siedzeniem nad demem kiedy to może totalnie nie mieć sensu bo nie trafię w gusta odbiorców, jakiś czas mnie nie było na scenie więc może dużo się pozmieniało po prostu

7

(893 odpowiedzi, napisanych Scena - 8bit)

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 ?

8

(893 odpowiedzi, napisanych Scena - 8bit)

Tebe nie tak , ja osobiście pisałem z XXL prywatnie i spoko , nie mam nic do gościa - jedyne co mogę zarzucić to nie wiem czy to forma trollowania czy po prostu stania sztywno przy swoim brak ochoty tutaj do kompromisu , wydaje mi się że wystarczyłoby przyjąć wspólnie pewien wypracowany wspólnie regulamin (czy zbiór zasad jak ktoś woli) co do prac zwłaszcza demoscenowych dla pewnych kategorii i się jego po prostu trzymać. Zapewne to by wyszło na zdrowie wszystkim bo przepychanki tworzą obraz patosceny a przy okazji demotywują ludzi do tworzenia czegokolwiek , przynajmniej ja to tak widzę

9

(893 odpowiedzi, napisanych Scena - 8bit)

Łą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)

10

(893 odpowiedzi, napisanych Scena - 8bit)

Każdy regulamin nakłada jakieś ograniczenia - ustalasz pewne reguły po to żeby się nimi kierować. Jak w życiu - nie srasz na środku chodnika mimo że technicznie możesz ale ze względu na innych użytkowników chodnika jest zakaz ...

Przykładem pewnych zasad jest używanie rejestru $d301 zamiast jego cienia co z punktu programisty robi to samo i nie ma znaczenia , problem jest kiedy masz jakieś dodatkowe urządzenia używające tej przestrzeni ...

Z takim postępowaniem mogę się zgodzić w jednym przypadku i nawet bym uznał że to ma sens - jeśli piszesz powiedzmy intro 16k na seryjne 64k atari i wpis do $d381 ze względu na proces np pakowania spowoduje że zyskasz te brakujące 2 bajty do wymaganej długości , bo $81 lepiej się spakuje niż $01

11

(893 odpowiedzi, napisanych Scena - 8bit)

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**** 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 ?

12

(893 odpowiedzi, napisanych Scena - 8bit)

napisałem że w dobrym tonie , zakładam że skoro ktoś ma rozszerzenie pamięci to może i mieć jakieś inne rozszerzenia więc po co mam rzucać kłody pod nogi , zwłaszcza że jakoś nie zauważyłem żebym musiał używać nielegali w swoich produkcjach. Przedstawiłem swoje zdanie z którym nie musi nikt się zgadzać , mam to ogólnie w dupie co inni myślą tak naprawdę , bo gdybym czytając takie tematy miał rozkminki to odniechciałoby mi się czegokolwiek zakodować ...

13

(893 odpowiedzi, napisanych Scena - 8bit)

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 ?

14

(893 odpowiedzi, napisanych Scena - 8bit)

Wiesz co ale to moim zdaniem nic złego - naturalna ewolucja sceny , przez internet, nowe możliwości techniczne dotyczące napędów czy sposobu przekazywania informacji jak choćby strony internetowe , serwery ftp zniknęli ludzie tacy jak Swaperzy a pojawili się dokumentaliści chcący uzbierać , usystematyzować , czy kolekcjonować dorobek scenowy i chwała im za to - robota skrybów jest znana od dawien dawna i dzięki temu mamy coś takiego co się nazywa spisaną historią wiec czemu odnośnie sceny nie miałoby nastąpić takie zjawisko ?

Co do Wild Compo czy samych compotów to zgodzę się i mam nadzieję że Grey , którego osobiście lubię wyciągnie wnioski z ostatniego compo na SV - przed samym compo ktoś powinien przeglądnąć prace , ocenić ich poziom i tak ustawić compo żeby było ciekawe - niestety oglądając streama mało co nie poszedłem w kimę bo samo demo compo czyli to na co zazwyczaj wszyscy czekją było o 3 w nocy , na samy party sporo ludzi już przysypiało , to zamęczenie ludzi SAM Coupe Compo czy Crazy Compo gdzie gość przez 10 minut opowiadał o czymś po angielsku było istną katorgą. Myślę że takie rzeczy powinno się przenieść na koniec i kto będzie chciał niech to ogląda - taka moja sugestia odnośnie samego sposobu przeprowadzania compotów ;)

15

(17 odpowiedzi, napisanych Zloty)

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 :)

16

(76 odpowiedzi, napisanych Programowanie - 8 bit)

żeby nie było , nie odpuściłem - wklejam kolejny update enginu 3d z VicDooma , tym razem kosztem rozdzielczości zwiększyłem 4 krotnie playfield, dodałem indykatory z kolorami po bokach na wzór Vic20 , przepisałem praktycznie od zera całą logikę wraz  systemem kolizji przeciwników z ścianami , obliczeń fireballi ,stos interkolizji gracza ze ścianami i same procedury "zrzucania gracza z ściany" oraz częściowo system stosu renedrowania. Jeszcze nie wszystko jest tak jak sobie wyobrażam ale przepisanie na nowo 18 tys lini w asmie i modyfikacja kodu zajmuje mi praktycznie każdą wolną chwilę wieczorami ;)
A efekt wygląda tak:

https://www.youtube.com/watch?v=7SnINvuIi8E

17

(76 odpowiedzi, napisanych Programowanie - 8 bit)

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

18

(76 odpowiedzi, napisanych Programowanie - 8 bit)

Ludzie ogarnijcie się z tym znaczkiem , kurna na razie to jest silnik wzięty wprost z VIC20 , kopilowany C z wstawkami assemblerowymi , więc mega kod zawiły i wolny, ciężko się to deassembluje oraz poprawia.
Już warstwę rysowania ogarnąłem , teraz walczę z warstwą renderingu ścian, kolejna będzie z renderingiem spritów i dopiero cała reszta - ogólnie bardzo dużo tam jest obliczeń typu mnożenie , 2 x dzielenie na 1 pionową linię i to idzie w pętli bez tablic.
Dopiero jak się z tym uporam to będę mógł zabrać się za wielkość okna.
Przy okazji kolizję liczy jako promień okręgu wg pitagorasa i pierwiastkuje wynik więc jest co ogarnąć.
Najpierw idzie kod kompilatora C do asm i wywalanie skoków przez programowy stos i każdy argument w C jako odobny jsr.
Więc jak dotrwam do końca to powinno dostać to kopa w małym oknie i wtedy będzie walka z większym ekranem.

19

(76 odpowiedzi, napisanych Programowanie - 8 bit)

Sikor napisał/a:

No ale przecież jest port "czegoś a la doom" - "Final Assault" czy jakoś tak to się nazywa...

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 ;)

20

(76 odpowiedzi, napisanych Programowanie - 8 bit)

XXL dzięki ale żeby to działało to jeszcze długa droga , w każdym razie da się zrobić port czegoś ala DOOM, mam nadzieję że dzięki temu będzie można ulepszyć silnik 3d napisany pod Atari ;)

21

(76 odpowiedzi, napisanych Programowanie - 8 bit)

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.

https://www.youtube.com/watch?v=Wng4bhNtcck

22

(76 odpowiedzi, napisanych Programowanie - 8 bit)

wygląda że się da to wyświetlić , na razie zrzut pamięci z emulatora VIC20 i uruchomionej gry.

PunBB bbcode test

Teraz zaalokowałem pamięć z vic 20 na atari i spróbuję bez wykrzaczenia skoczyć w miejsce gdzie monitor vic20 zatrzymał kod z zapamietanym stanem rejestrów.

Update wkrótce czy się udało - bo kod też skacze do kernela VIC20 ....

23

(76 odpowiedzi, napisanych Programowanie - 8 bit)

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ć ;)

24

(76 odpowiedzi, napisanych Programowanie - 8 bit)

Wiec jakbyś potrzebował żeby coś zoptymalizować itp to daj znać

25

(76 odpowiedzi, napisanych Programowanie - 8 bit)

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