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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthor0xF
   • CommentTime25 Feb 2023

    
   ->link<-
   

   It is still kind of amazing to me that the Atari Jaguar designers just went and made a custom RISC processor for their console (augmenting the standard m68k) versus using something off the shelf. They had some frustrating bugs, but pretty good performance for the day.
   
2. • 2:
      
     CommentAuthorCyprian
   • CommentTime25 Feb 2023

    
   Jag to niełatwa w programowaniu konsola. Z tym że brak zrozumienia działania procesora to bug ale po stronie programisty.
3. • 3: CommentAuthorPawex (RTG)
   • CommentTime26 Feb 2023

    
   Zdaje się, że Carmack do programowania Doom'a używał komputera NeXT z procesorem Motoroli.
4. • 4: CommentAuthorjury
   • CommentTime26 Feb 2023 zmieniony

    
   Z tego co kojarzę, to nie, szczególnie, że to by było jakoś mocno dookoła i bez sensu tworzyć tak skomplikowany wtedy silnik na procesor zupełnie inny niż na który miał wyjść docelowy produkt.
   Ale edytor poziomów Dooma podobno faktycznie był stworzony na NeXTie. Tak przynajmniej podaje autor tego ów dokumentu:
   
   ->link<-
5. • 5: CommentAuthorPawex (RTG)
   • CommentTime26 Feb 2023 zmieniony

    
   Tutaj znalazłem coś takiego:
   ->link<-
   
   "Doom was developed on NeXT workstations, under the NeXTSTEP operating system. The final game engine was programmed in C, and the editing tools were written in Objective-C. The engine was first compiled with Intel's C compiler for DOS, but later Watcom's compiler was used."
   
   tutaj też coś w tym temacie:
   ->link<-
   
   ..ale być może faktycznie chodziło tylko o edytor poziomów.
   
   P.S.
   Oczywiście w wypowiedzi Carmacka cytowanej w pierwszym poście jeżeli się nie mylę chodzi o GPU Jaguara.
6. • 6:
      
     CommentAuthorCyprian
   • CommentTime27 Feb 2023

    
   też mi się wydaje że chodzi o GPU. Chyba nie za bardzo chyba łapał że pipeline jest głębszy niż w ówczesnych procesorach więc że wynik instrukcji nie pojawia się od razu w rejestrach, no i chyba też nie załapał jak działa "GPU in main"
7. • 7:
      
     CommentAuthorgalu
   • CommentTime27 Feb 2023

    
   Polecam publikację “GAME ENGINE BLACK BOOK: DOOM”: ->link<- (an stronie jest podlinkowany PDF)
8. • 8: CommentAuthorjury
   • CommentTime27 Feb 2023

    
   Wow, zapowiada się wyśmienita lektura! Zakolejkowane!
9. • 9:
      
     CommentAuthorcrrn
   • CommentTime27 Feb 2023

    
   @galu
   dzięki. świetna pozycja. będzie czytane i analizowane.
10. • 10:
       
      CommentAuthorCyprian
    • CommentTime27 Feb 2023 zmieniony

     

    galu:

    Polecam publikację “GAME ENGINE BLACK BOOK: DOOM”: ->link<- (an stronie jest podlinkowany PDF)

    
    dobra książka, gościu udostępniał również PDF “GAME ENGINE BLACK BOOK: WOLFENSTEIN 3D”, ale teraz tego nie widzę na jego stronie: ->link<-
11. • 11:
       
      CommentAuthorlaoo
    • CommentTime27 Feb 2023

     
    @Cyprian z tymi bugami, to kilka rzeczywistych bugów akurat jest. Jest np. rozdział w dokumentacji o różnicach pomiędzy wersją developerską sprzętu, a wersją retail (poprawiono kilka bugów) i też jest rozdział punktujący co nie działa tak jak by się wydawało, że powinno. Brakło po prostu co najmniej jednej iteracji na doszlifowanie sprzętu.
12. • 12: CommentAuthorsolo/ng
    • CommentTime28 Feb 2023 zmieniony

     
    A jak bylo z tym dostepem GPU code z RAMu? Czy jest jak mialo byc z zalozen projektu - via ten gpu 4kb cache blok czy mialo byc inaczej, ale wyszlo jak wyszlo?
13. • 13:
       
      CommentAuthorCyprian
    • CommentTime28 Feb 2023 zmieniony

     
    GPU ma dostęp do 24bitowej szyny adresowej, czyli widzi zarówno swój RAM (4KB), pamięć główną (2MB) jak i adresy sprzętowe. Może pobierać dane z dowolnego obszaru jak i wykonywać kod w dowolnym obszarze. Czyli jest jak miało być.
    
    Z tym że ktoś kiedyś nie ogarniał uruchamiania kodu GPU z pamięci głównej więc stwierdził że nie da rady i że jest to bug. Oczywiście ze względu na 64bitową szynę danych i 32bitowy GPU są pewne obostrzenia dotyczące skoków w pamięci głównej.
    
    Co więcej pewne "bugi" GPU czy DSP opisane w dokumentacji (div, load/moveq, czyli opóźniona widoczność wyniku w rejestrach) nie do końca są bugami tylko efektem ubocznym głębokiego pipeline.
14. • 14:
       
      CommentAuthorDracon
    • CommentTime28 Feb 2023

     

    Cyprian:

    dobra książka, gościu udostępniał również PDF “GAME ENGINE BLACK BOOK: WOLFENSTEIN 3D”, ale teraz tego nie widzę na jego stronie

    
    Bo trzeba odpowiednio zapytać o to Gugla. :)
    Dzięki, że w ogóle wspomniałeś o tym tytule, nie znałem tego.
    A link do zassania jest tutaj, autor po prostu nie podał go na stronie:
    ->link<-