Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Cosmic Hero 2 Bohater ratujący Ziemię w kryzysowej sytuacji powraca po 30 latach.
Strony Poprzednia 1 2 3 4 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Święty zdecydował że to koniec zabawy:
Zajebiste. Graubym.
nadchodzi petarda
ciiiiii
z Rapidusem można większe okno gry zrobić, no ale pewnie nielegale, więc ...
co zaproponujesz zamiast:
lsr @
ldx #$60
sax tex ; illegal
alr #$18 ; illegal
sta col
zreszta Święty jest entuzjastą 65816 wiec pojdzie :-)
Ostatnio edytowany przez xxl (2022-03-10 09:13:54)
Święty zdecydował że to koniec zabawy:
...co za szczęście że znalazłem lupę.
kolejne potwierdzenie ze Amiga i Atari 8 bit to jedna rodzina :-) pamietam pierwszego glooma w okienku wielkosci znaczka pocztowego :D
Jeśli tylko na Rapidusie będzie można powiększyć okno na cały ekran (jak na Amidze z akceleratorem) to mi to nie przeszkadza.
Ostatnio edytowany przez perinoid (2022-03-10 15:04:37)
zastanawiam sie dlaczego nikt nie napisal w bejzolu 3d dla rapidusa, raycastera pewnie w 10 liniach by sie zmiescil.
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.
to sie nazywa marskosc dupy. juz w tym moemencie ten vicdoom jest bardziej zaawansowanym 3d od wszystkiego co na atari powstalo w tym temacie.
a tymczasem w swiecie zwyklego raycastingu mala zmiana w obliczeniu przesuniec.
Przy okazji kolizję liczy jako promień okręgu wg pitagorasa i pierwiastkuje wynik więc jest co ogarnąć.
Gdybyś chciał pozostawić algorytm kolizji, to ostatnio było przygotowane świetne porównanie i poprawianie algorytmów pierwiastkowania dla 6502:
https://github.com/TobyLobster/sqrt_test
Święty ciśnie temat...
miejscami za szybko to działa...
da się to spowolnić troszkę?
Proponuję to zmniejszyć jeszcze o połowę, to będzie jeszcze ze dwa razy szybsze :D
po zmniejszeniu o połowę będzie działało 4 razy szybciej, podobnie po zwiększeniu x2 będzie działało 4 razy wolniej,czuwaj!
@gorgh: Nie do końca, bo część operacji robi się w jednej płaszczyźnie - to jest raycasting a nie Ray tracing.
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
Święty uderza:
zapinkala :-)
jakby byla jakas magiczna sztuczka ktora w 3 bajtach wykona to co ponizej to by byl niezly speedup
bajt w akumulatorze:
:4 asl @
lub
:4 lsr @
tay
lda (lookup_table_ptr),y:-) dobre :-)
ale pozylem sie tego calkowicie. zapisalem tekstury w ten sposob:
przykladowy bajt tekstury:
11100100
przygotowalem tak, zeby kazdy "pixel" tekstury zajmowal jeden bajt:
11111111
10101010
01010101
00000000
i nie trzeba tabelek (w petli rejest Y jest kosztowny) dzieki czemu skalowanie zrobilo sie sporo szybsze tyle ze tekstura urosla x4 ;-)
co ja patrze... vicDOOM na Atari ma juz statystyki :-) ... no i ciągle za szybko dziala:
---
konsumujac intro ""Broda" Foxa zauwazylem, ze sklejanie bajtu realizowane jest na przesunieciach bitow ... moze to lepszy sposob od AND/OR...
Święt nie śpi... właśnie pojawił się level: Russian Hangar z oryginalnym dziękiem emulowanym na POKEY
Strony Poprzednia 1 2 3 4 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.096 sekund, wykonano 20 zapytań ]