ArmA 2 - gdzie się podziały dynamiczne zniszczenia?

[Rainbow]

1. Archeolog, leć na Bliski Wschód i tam szukaj korzeni Sarmackich, jak nasi panowie szlachta w XVII-XVIII wieku.

2. Muszę się zgodzic z FireFly. Karty fizyczne to już historia. Po wielkich i szumnych zapowiedziach jak miało to wszystko wyglądać doszło to faktycznego testu w mn. Ghost Recon, gdzie k. fizyki zamiast przyśpieszyć grę odciążając procek ta dodatkowo spowalniała, ponieważ k. grafiki musiała dodatkowo przetwarzać grafikę tych wszystkich latających na około efekciarskich elementów.

3. Tytuł tematu to pytanie retoryczne odnoszące się do linka z blogu BISu. Wystarczy, że byś go przeczytał i zrozumiał byś jego sęk.

[ArthurNeo]

Nie jestem zbyt na czasie przyznaję... niewiem czy ktoś chce żeby było to razem czy osobno i nie piszę wogóle o tym... twierdzę tylko, że procesory fizyczne byłyby bardzo dobrym rozwiązaniem właśnie do takich zastosowań m.in. dynamicznych zniszczeń. Chodzi mi o sam fakt istnienia takich procesorów a czy one będą zaimplementowane w CPU i czy to będzie razem z GPU czy nie... nie zagłębiam się w to na ten temat. Dwa lata temu testowano jedną z takich kart na jakiejś grze (nie pamiętam jakiej) i wyraźnie można było zauważyć realistyczne poruszanie się obiektów w grze, ich naturalne zachowanie właśnie z zastosowaniem tej karty która na dodatek odciążała procesor CPU.
Niewiem jaka jest przyszłość tych kart ale myślę że to jest dobre... bo chyba przyznacie, że np. poruszanie się żołnierzy w Armie raczej nie jest zbyt naturalne.
Co do programowania... owszem mam pojęcie. I śmiało mogę stwierdzić, że w programowaniu nie ma żadnych barier. Bo jak ktoś pisze, że nie da się zaprogramować dynamicznych zniszczeń to jest po prostu śmieszny. A wracając do procesorów fizycznych... dzięki nim programowanie naturalnych zachowań obiektów w tym także dynamicznych zniszczeń byłoby dużo prostsze. To chyba nie jest jakaś filozofia?

[kondor]

Dwa lata temu testowano jedną z takich kart na jakiejś grze (nie pamiętam jakiej) i wyraźnie można było zauważyć realistyczne poruszanie się obiektów w grze, ich naturalne zachowanie właśnie z zastosowaniem tej karty która na dodatek odciążała procesor CPU.

trzebaby pisać grę dedykowaną na takie procesory, tak jak BIS zrobił z ArmA2 i dwoma rdzeniami, jednak minus jest taki, że na kompach zwykłych zjadaczy chleba będzie bardzo duży spadek wydajności.

bo chyba przyznacie, że np. poruszanie się żołnierzy w Armie raczej nie jest zbyt naturalne.

co to ma wspolnego z procesorami od fizyki?

Co do programowania... owszem mam pojęcie. I śmiało mogę stwierdzić, że w programowaniu nie ma żadnych barier.

chodziło mi o bariery natury ludzkiej, praktycznej - spytam: wiesz czemu nie robi się takich gier w assemblerze?

Bo jak ktoś pisze, że nie da się zaprogramować dynamicznych zniszczeń to jest po prostu śmieszny.

poczytaj blog Spanela, choc mozesz po prostu uznać, że się nie zna w ocenie sytuacji lub, że mu się nie chce

A wracając do procesorów fizycznych... dzięki nim programowanie naturalnych zachowań obiektów w tym także dynamicznych zniszczeń byłoby dużo prostsze. To chyba nie jest jakaś filozofia?

gdyby się przyjęły powszechnie, to możnaby myśleć o ich wykorzystaniu

[ArthurNeo]

trzebaby pisać grę dedykowaną na takie procesory, tak jak BIS zrobił z ArmA2 i dwoma rdzeniami, jednak minus jest taki, że na kompach zwykłych zjadaczy chleba będzie bardzo duży spadek wydajności.

masz rację... nie brałem pod uwagę faktu jak gra będzie chodzić przez to na słabszych kompach, ale powiedzmy sobie szczerze OFP i ARMA i tak są bardzo wymagające... więc to jest taki minus od samego początku: "wymagania sprzętowe".

co to ma wspolnego z procesorami od fizyki?

"funkcje" jakie są zaimplementowane w procesorach fizyki ułatwiają programowanie naturalnych zachowań obiektów, zgadza się?

chodziło mi o bariery natury ludzkiej, praktycznej - spytam: wiesz czemu nie robi się takich gier w assemblerze?

Rozumiem... mi chodziło o bariery techniczne.

poczytaj blog Spanela, choc mozesz po prostu uznać, że się nie zna w ocenie sytuacji lub, że mu się nie chce

widocznie ma jakiś powód... moim zdaniem uznał, że dynamiczne zniszczenia będą znacznie podnosiły i tak już wygórowane wymagania sprzętowe i nie chciałby ograniczyć liczby "zainteresowanych" tą grą. Ale to tylko moje zdanie...

gdyby się przyjęły powszechnie, to możnaby myśleć o ich wykorzystaniu

Tu także się z Tobą zgodzę... i miejmy nadzieję że się przyjmą w jakiejkolwiek postaci. Przydałoby się to w Armie czy OFP. Dźwięk w grach jest na wysokim poziomie, grafika także... tylko fizyka jakoś zostaje w tyle.

Pozdrawiam

[Forrestal]

co to ma wspolnego z procesorami od fizyki?

"funkcje" jakie są zaimplementowane w procesorach fizyki ułatwiają programowanie naturalnych zachowań obiektów, zgadza się?

Nie, zadne procesory przetwarzajace fizyke nie ulatwiaja programowania, wrecz odwrotnie. Zaleta jest to ze sa dedykowane pod obliczenia tejze fizyki choc po wykupieniu przez Nvidie Ageii karty z seri GeForce 8xxx i 9xxx maja byc "odpowiednikamo" PhysX'a

chodziło mi o bariery natury ludzkiej, praktycznej - spytam: wiesz czemu nie robi się takich gier w assemblerze?

Rozumiem... mi chodziło o bariery techniczne.

To jest ciekawe, kiedys doszedlem do wniosku ze kilka rzeczy z ArmA moznaby skrobnac w assemblerze - rzeczy mniej istotnych a jednak majacych wplyw na wydajnosc (obsluga .jpg, .tga badz .paa i innych plikow)

[klamacz]

@Forrest: gwarant, ze sa napisane w asm

[Forrestal]

@Forrest: gwarant, ze sa napisane w asm

Pewny? Sie zastanawiam skad biora sie takie problemy z obsluga .jpgow w OFP/ARMA. Przeciez tak to daje po wydajnosci ze ja piernicze a juz teksturki jakies w .paa/.pac dzialaja duzo lepiej.

[klamacz]

@Forrest: gwarant, ze sa napisane w asm

Pewny? Sie zastanawiam skad biora sie takie problemy z obsluga .jpgow w OFP/ARMA. Przeciez tak to daje po wydajnosci ze ja piernicze a juz teksturki jakies w .paa/.pac dzialaja duzo lepiej.

z prostej przyczyny, ze jpg oblugiwane jest przez jakis jpglib zewnetrzny, zas paa i pac to pochodne dds-ow, ktore sa obslugiwane wewnetrznie przez directxa. Tak czy owak obie metody powinny byc i sa zaimplementowane na jak najnizszym poziomie (np. wlasnie asm)

[ArthurNeo]

Forest ja mam swoje zdanie a ty masz swoje jeżeli chodzi o procesory fizyczne, fajnie jest kiedy się tak dyskutuje, lubię to... a wracając poprostu myślę, że procesory te ułatwiają programowanie naturalnych zachowań obiektów z prostej przyczyny... w procesorach tych już są zaimplementowane "stałe fizyczne" i nie trzeba ich wałkować za każdym razem od początku tym bardziej, że efekt potem jest jaki jest kiedy każdy programista fizykę widzi inaczej. Mówiąc "programowanie jest łatwiejsze" nie mówię w sensie że jest przy tym mniej pracy bo to nie prawda tylko jest lepszy efekt. Napewno procki te dodają urocku każdej grze co widać było na testach tych kart... Chodzi mi oczywiście o ułatwienie techniczne... sam efekt działania tego w grze.

Piszesz, że zaletą jest to że procki są dedykowane pod obliczenia tej fizyki... i właśnie o to chodzi, też uważam że to zaleta i to bardzo duża. Może w końcu w grach każdy ruch, zachowanie i wzajemnie oddziaływanie obiektów będą naturalne.

Co do pytania czy wiem czemu nie robi się takich gier w assemblerze? trudno mi odpowiedzieć na to pytanie ale wg. mnie lenistwo się kłania aczkolwiek nikomu lenistwa nie zarzucam bo wiem jaką czasochłonną i ciężką pracą jest programowanie. Szacunek.

[Rainbow]

Dajcie spokój już z tymi kartami fizycznymi. Nadchodzą procki 12 rdzeniowe. Poświeci się te 2 czy 4 rdzenie na fizyke i wio

[ArthurNeo]

Właśnie... jeszcze się może okazać że to pójdzie w całkiem innym kierunku peace