Prawdę mówiąc, pod względem jakości grafiki większe wrażenie zrobił na mnie DLSS 5 dodawany do starych gier przez modderów.
Zastanawiam się, czy robienie tak wysokobudżetowych produkcji jest dzisiaj opłacalne. Przy kosztach przekraczających miliard dolarów gra musi się sprzedaż w setkach milionów egzemplarzy.
Taki wynik będzie coraz trudniej uzyskać, biorąc pod uwagę rosnące ceny sprzętu i dużą konkurencję na rynku rozrywki.
Zresztą z mojej perspektywy Rockstar skończył się na Lemmings. ;-)
Apparently AMD docs initially contained information about PSP in Steamroller microarchitecture, but it was removed in later documents. It appeared officially in the Excavator.
Maybe it could not be enabled in time for the release, or there were some issues with the new hardware?
https://freundschafter.com/amd-processors-without-amd-psp-secure-technology/
Zaskoczyłeś mnie tymi opiniami. Podmiana alokatora w C++ wygląda dla mnie na banalną rzecz (podmieniałem na różne).
Może trzeba zaprojektować język, w którym każda funkcja na jawne zarządzanie stosem CPU. Instalator NSIS ma taki i pisało się bardzo nieprzyjemnie, więc naśladowca ma pewnie szansę odnieść sukces.
Nie podoba mi się zarządzanie pamięcią w tym języku. W C++ i Rust również można robić ręcznie alokacje, ale domyślne działanie oparte na globalnym alokatorze jest wygodniejsze.
Zig aktywnie przerzuca odpowiedzialność za robienie tych fikołków na użytkownika. ArrayList był kiedyś “zarządzany” (wiedział jakiego alokatora ma użyć). Teraz każde wywołanie append wymaga podania alokatora, który tak czy inaczej musi być zawsze tym samym obiektem, bo inaczej dostaniemy niezdefiniowane zachowanie.
W efekcie programista musi powielać kod, który powinien znaleźć się w sensownie zaprojektowanej bibliotece standardowej.
Odnośnie opcjonalności niektórych fragmentów specyfikacji, wydaje mi się, że w świecie embedded produkuje się binarki pod konkretną platformę? Osobiście nie spodziewałbym się, że firmware skompilowany pod jakiś procesor będzie działać bez problemu po migracji na inne rozwiązanie sprzętowe.
Amiga Corp ma prawa do wszystkiego na m68k, Hyperion do wszystkiego na innych CPU.
AmigaOS 3.x będzie utrzymywany przez AmigaCorp, nowsze wersje przez Hyperiona. Obecnie firmy dyskutuja nad przekazaniem praw do patchów które w ostatnich latach zrobił Hyperion,.
W dalszym p[lanie rozważana jest publikacja kodu źródłowego, ale tylko do researchu i prywatnych modyfikacji (branding / znaki towarowe w kodzie są nadal zastrzeżone).
Kilka firm pracuje nad projektami na licencji (między innymi THEA1200).
Nie wiem, czemu autor buduje te wszystkie rpmy i deby. Wydaje mi się, że łatwiej jest po prostu opublikować źródła i pozostawić całą resztę maintainerom dystrybucji. Na systemach pokroju Debiana czy Ubuntu nie instaluję niczego z nieoficjalnych repozytoriów.
Moim zdaniem podstawą w takich projektach powinno być przygotowanie pakietu, który można zainstalować jednym poleceniem. Wystarczy do tego statyczna binarka albo AppImage.
Nie znam się na zarządzaniu firmą, ale zastnawiające jest dla mnie, czemu zdecydowali sie robić wszystko we własnej “fabryce”. Włącznie z produkcją PCB i frezowaniem.
Mam wrażenie, że wymagało to sporego nakładu inwestycyjnego, podczas gdy samą obudowę pan Chinczyk pewnie zrobiłby im za ułamek pieniędzy (i do tego lepiej). Budują software jako open source, ale nie chcą nikomu zlecić produkcji sprzętu?
Szkoda, że nie pokazali jak wygląda proces analizy problemu i projektowania rozwiązania.
Wydaje mi się, że to jest pewnie najtrudniejszy etap całeg procesu.
Trudno mi uwierzyć, że zrobiła to jedna osoba. Podejrzewam, że część kodu albo assetów została kupiona (zlecona podwykonawcom).
Tak czy inaczej, wygląda bardzo dobrze.
Czytalem ostatnio artykuł o tym jak amerykańskie wojsko rozdawało żołnierzom okaryny w czasie 2 WŚ. Podobno miało to poprawić morale.
Technologia produkcji plastikowych fletów prostych jeszcze wtedy nie istniała.
Ciekawe jakie jest opóźnienie pod Windows na podobnej konfiguracji.
Powinien być jakiś urząd odbierający komputery takim ludziom.
Tylko jaki narzut na wydajności ma kompilacja do wasm zamiast do natywnej architektury?
Nie testowałem, ale podejrzewam, że da się zauważyć gołym okiem.
Trzeba wywalić fread i fwrite z biblioteki standardowej. To relikt przeszłości. ;-)
Microsoft znowu próbuje zabić IRCa.
Widziałem takie API w innych projektach. Zaletą jest to, że masz ciągły obszar danych bez odwołań do innych buforów.
Przypomnę tylko, że w Win32 trzeba przed wywołaniem niektórych funkcji wypełniać rozmiary w przekazywanych strukturach.
Rozumiem, że to jakieś tech demo, bo model jest chyba za mały, żeby dolecieć na orbitę?
To jeszcze nic. Wzgórze z Windows XP w rzeczywistości wygląda tak: