atarionline.pl Nowa gra "VICDOOM" - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1:
       
      CommentAuthorKaz
    • CommentTime22 Mar 2022 zmieniony
     
    Połączenie Świętego z Atari zawsze daje coś ciekawego :). A to dopiero początek.

    • 2: CommentAuthorgorgh
    • CommentTime22 Mar 2022
     
    nareszcie gra 3d na atari z normalnymi przeciwnikami, wierzę w Świętego, że uda mu się też powiększyć pole gry
    • 3:
       
      CommentAuthorKaz
    • CommentTime22 Mar 2022
     
    Ja myślę, że to dopiero przymiarki, takie rozeznanie tematu przed właściwą grą! :)
    • 4: CommentAuthortebe
    • CommentTime22 Mar 2022
     
    rozdzielczość aktualna to 40 x 80 pikseli, piksel 2x1

    tryb Konopa (16 odcieni szerości itp) to 64x60, 80x60, 96x60

    ogólnie w pionie stracimy, w poziomie zyskamy, albo zachowamy tryb 4 kolorowy i będziemy zwiększać okno posiłkując się Rapidusem
    • 5:
       
      CommentAuthorJacques
    • CommentTime22 Mar 2022 zmieniony
     
    A bardziej popularne VBXE tu nic nie pomoże w obliczeniach?
    • 6:
       
      CommentAuthorshanti77
    • CommentTime22 Mar 2022
     
    VBXE to tylko karta graficzna, nie posiada żadnych mocy obliczeniowych.
    • 7: CommentAuthortebe
    • CommentTime22 Mar 2022
     
    VBXE upraszcza stawianie pikseli, 1 bajt = 1 piksel

    nie trzeba składać 4 pikseli w 1 bajt, kilka cykli na bajt VBXE zaoszczędzi, ale to nie zastąpi Rapidusa
    • 8: CommentAuthorCyprian
    • CommentTime22 Mar 2022 zmieniony
     
    a czy blitterem VBXE nie można teksturować? np. wypełniać jedną kolumnę o szerokości 1px teksturą która jest w pamięci VBXE?

    Niby jakąś opcję skalowania ma:
    "blitter with 7 modes of operations capable of zooming displayed data"
    • 9: CommentAuthortbxx
    • CommentTime22 Mar 2022
     
    Zacytuję autora konwersji ;)

    "Ktoś zadał sobie wiele trudu żeby to przenieść (na VIC20) ale poza wstawkami assemblerowymi cały kod skompilował w C i przez to wyszedł potwór w postaci kodu.
    To co wyszło z kompilatora to dramat:
    ładowanie argumentów i skoki do każdej pod procedury osobno.
    Zdeaseblowalem kod - dzięki temu że mam listę adresów wszystkich procedur w C mogę sobie wpisać nazwy procedur i adresy
    a mając kod w C dojść co robi jaka zmienna w każdym razie to jest istny Armagedon"

    Jest przepisane 60% kodu z VIC20, całość się optymalizuje i ma być lepiej ;)
    • 10:
       
      CommentAuthorKaz
    • CommentTime24 Mar 2022 zmieniony
     
    Dzięki Tomku za podesłanie wypowiedzi Świętego. Widać, że przymierza się do czegoś swojego. Zresztą, stare już demko "Maze" pokazuje, w którą stronę to będzie szło. A przecież mówił w Tarnowie, że da sie jeszcze lepiej! :)

    • 11: CommentAuthortebe
    • CommentTime24 Mar 2022
     
    wkleję wypowiedź Świętego z innego forum, bo znowu zaczynacie błądzić...

    "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"
    • 12:
       
      CommentAuthorKaz
    • CommentTime18 Apr 2022
     
    Sprzed godziny:

    Święty:

    Po ponad miesiącu intensywnego spędzania każdej minuty na deassemblacji, analizie kodu, porównaniu z kodem w C oraz ASM, powstał kolejny update VICDOOM-a na ATARI XL/XE - kod ma ok 19500 lini w ASM, kompiluje się do ponad 32kb , w kazdym razie chodzi dość przyzwoicie patrząc jaka tam jest matematyka - mnożenie 32 bitowe, dzielenie , pierwiastki kwadratowe oraz potęgowanie .... na pocesorze który nie ma nawet mnożenia.
    Niedługo pojawi się plik wykonywalny z możliwością pogrania sobie na razie na jednym levelu.

    Pojawił się dźwięk - efekty są bezpośrednio z oryginalnej gry z pliku wad, wersja na pc speakera.


    • 13: CommentAuthorświęty
    • CommentTime20 May 2022 zmieniony
     
    ż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:

    • 14:
       
      CommentAuthorKaz
    • CommentTime20 May 2022
     
    Ocie pępek! Super to wygląda, jest szybkie, a przeciwnicy ogromni :)
    • 15:
       
      CommentAuthorjhusak
    • CommentTime20 May 2022
     
    Bardzo fajne - ja bym jednak zwiększył rozdzielczość poziomą dwukrotnie, bo za wąskie to jak dla mnie - a wtedy 1 piksel=1 bajt. Tada! A przynajmniej taki test by zrobić.
    • 16: CommentAuthorilmenit
    • CommentTime21 May 2022
     
    Też uważam, że warto przetestować rozciągnięcie poziome. Mapa jak e1m1 z Dooma (bez różnic wysokości), ale wrażenie klaustrofobiczne poprzez bardzo wąskie korytarze.
    • 17: CommentAuthorBelzebub
    • CommentTime21 May 2022 zmieniony
     
    Wow świetnie to wygląda i szybko chodzi
    Mam nadzieję że wyjdzie z tego fajna gra
    Przydałby się u dołu ekranu widok broni, jakiś mały pistolecik czy coś
    • 18:
       
      CommentAuthorjhusak
    • CommentTime21 May 2022
     
    @Belzebub, to oczywiste :) święty się skupia na tym, czy to w ogóle ma sens (widać, że ma), bo może napotkać jakiś problem nie do przejścia. A na koniec statyczne graficzki i ogólnie łatwe rzeczy.
    • 19: CommentAuthorświęty
    • CommentTime22 May 2022
     
    Panowie wiadomo że coś będę dalej działał , najbardziej mi zależy żeby wszystko zabierało jak najmniej czasu procesora a to ciężkie jest kiedy jest w cholerę obliczeń zwłaszcza 32 bitowych signed ... Do tego dochodzi pitagoras czyli odległość od gracza do przeciwnika to x2+y2=len2 więc len= sqr(len2) , jest tam trochę uproszeczeń ale w przypadku liczenia interkolizi między graczem a ścianami oraz sektorami czy przeciwnikami a ścianami oraz cała sztuczna inteligencja graczy (kod rodem id software - wystarczy przeanalizować kod vicdooma w C) , to wychodzą obliczenia skalarne wektorów , których do końca nie bardzo rozumiem więc optymalizuję na zasadzie analizy kodu ;)
    W każdym razie nie poddaję się i teraz zamierzam walczyć z większą rozdzielczością poziomą i wtedy zobaczymy co dalej
    • 20: CommentAuthortebe
    • CommentTime22 May 2022
     
    po tylu latach w końcu znalazł godne wyzwanie :)
    • 21: CommentAuthorBelzebub
    • CommentTime22 May 2022
     
    Widać że kolega podszedł do tematu bardzo ambitnie
    To jak już teraz wygląda i działa to jest naprawdę ok
    Niech gra ma kilka etapów, obrazek tytułowy i na zakończenie gry oraz widok broni o którym pisałem i mamy nową gotową doom-o podobną grę na Atari XL/XE.
    • 22: CommentAuthoremkay
    • CommentTime22 May 2022
     
    Sorry, couldn't resist.

    Thanks, Swiety, for enhancing the screen size.

    • 23: CommentAuthorpin
    • CommentTime22 May 2022
     

    święty:

    Panowie wiadomo że coś będę dalej działał , najbardziej mi zależy żeby wszystko zabierało jak najmniej czasu procesora a to ciężkie jest kiedy (...)


    Robisz jakąś furtkę pod turbo na CPU (np większa rozdzielczość itd), czy taka opcja nie jest przewidywana?
    • 24: CommentAuthortebe
    • CommentTime23 May 2022
     
    tutaj Pin masz taką poprawioną wersję :)

    • 25: CommentAuthorpin
    • CommentTime24 May 2022
     
    Dzięki Tomuś że mnie oświeciłeś. Faktycznie :)
    • 26:
       
      CommentAuthorsun
    • CommentTime26 May 2022
     
    W zasadzie jak widać, potrzebny jest avg cart, player sterowany joyem/klawiaturą, render z map DOOMa - ciekawe ile by to zajęło, każdy możliwy kąt, podejście itp. ;) - i można giercować w 50 fps na Atari :)
    • 27: CommentAuthorpirx
    • CommentTime26 May 2022
     
    obliczenia były przeprowadzane. wyszło zaskakująco dużo klatek, jeśli chciałoby się mieć płynną animkę. w ogóle nie myślimy o kucaniu i skakaniu. w czasach compact flashy i myide kiedy o tym myślałem to się nie spinało, ale teraz na microsd 128GiB....
    • 28:
       
      CommentAuthorMaW
    • CommentTime26 May 2022
     

    jhusak:

    Bardzo fajne - ja bym jednak zwiększył rozdzielczość poziomą dwukrotnie, bo za wąskie to jak dla mnie - a wtedy 1 piksel=1 bajt. Tada! A przynajmniej taki test by zrobić.
    Przyłączam się - tryb z szerszymi pikselami nie zabierze cykli, a będzie mniej klaustrofobicznie ;)