2. Fórumok
  3. Videokártyák
  4. Minden, amit a DirectX 11.1-ről tudni kell
Keresés

Új hozzászólás Aktív témák

  • #66 Pikari veterán Maegoss #64
    Új Válasz #66
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Pikari

    veterán

    válasz Maegoss #64 üzenetére

    Lehet, hogy értesz a témához de eléggé elvakultnak tűnsz, ami sokat ront a szavahihetőségeden...

    erősen téves elképzelés azt hinni, hogy én azért járok erre a fórumra, hogy a szavahihetőségemet, hozzáértésemet - vagy bármi mást - bizonyítsak.

    Azt el tudom hinni, hogy speciális felhasználásra hatékonyabb a szoftveres render, de általánosságban kizártnak tartom, hogy a szoftveres render gyorsabb/hatékonyabb/költségkímélőbb lenne, mint a hardveres (API-val).

    hinni a templomban kell, kizártnak tartani meg akkor, ha már kipróbáltad. (én megtettem)

    Szóval szerinted dobjuk ki a GPU-kat a kukába és térjünk vissza a GPU-mentes időszakba, mint kb. 10 évvel ezelőtt? Emlékeim szerint a Radeon volt az egyik első GPU (HW TnL-gal).

    tulajdonképpen igen. persze az azért jó, ha az oprendszer guiját a továbbiakban is ki lehet rajzolni valamivel a képernyőre, szóval csak ésszel. az első tnl-es gpu valamelyik s3 grafikus kártya volt, talán a savage 2000, de bugos volt benne, ezért szoftveresen letiltották később. a második - amely néhány nappal ezután érkezett, és tnl-t tudott - az a geforce 256 volt. ezeket gpunak mellesleg nem igazán lehet nevezni, a tnl azért nem volt egy olyan nehézsúlyú dolog, inkább csak a vbo-k miatt érdekes.

    Arra is kíváncsi lennék, hogy a játékfeljesztőknek mennyi időbe és pénzbe kerülne egy szoftveres rendert használó játékmotort megírni (ami annyit tud és úgy néz ki mint egy mai korszerű játékmotor) és az hogyan futna a számítógépek többségén..

    nagyjából ugyanannyiba kerülne, mint opengl ES2-vel, lényegében ugyanazokat az algoiritmusokat kell implementálni mindkét esetben. persze hoszabb távon a szoftveres rendererrel talán még előbbre is lennének, mert ha újabb képességekre van szűkség, vagy platformokra, a portolhatóság és továbbfejleszthetőség nem jelenthet gondot egy algoritmikus implementáció esetén.

  • #54 Pikari veterán kisfurko #52
    Új Válasz #54
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Pikari

    veterán

    válasz kisfurko #52 üzenetére

    nos, nekem az ati radeon 9800 hajlamos volt ilyen 20 pixelnyi blokk nagyságú árnyékartifactokat csinálni, az meg azért eléggé feltűnő, ocsmány, és lehangoló.

    a szoftveres renderert meg meg kell írni - egyszer. utána viszont tetszőlegesen skálázhatod, ha az effektekről van szó, nem vagy idegen grafikus pipelinere kényszerítve. a raszterizálás elhagyása nem ekvivalens azzal, hogy processzoron számolunk, elvégre nem csak ray tracelni, hanem raszterizálni is lehet cpu-n. a cpu-ra nagyon szép és gyors raszteres renderert lehetne írni, de én nem raszterezésben utazom már, és nem is a szép grafikában (hanem a gyorsban). a d3d-ben meg az opengl-ben konkrétan az a nem jó, hogy implementálnak egy olyan grafikus pipelinet, amire amúgy nincs is szűkségünk: azonos sziliciummennyiség mellett egy fejlesztő az önmagának fejlesztett, és/vagy célspecifikus, célirányos rendererje nagyságrendekkel gyorsabb, mint egy előre bespecifikált, túlmisztifikált, túlbonyolított, vagy épp szétspórolt api, mint amilyen az opengl, vagy direct3d bármely derivációja. in my oppinion.

    (privátban tudok erről több paramétert adni, ha dobsz egy skype címet.)

  • #43 Pikari veterán kisfurko #32
    Új Válasz #43
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Pikari

    veterán

    válasz kisfurko #32 üzenetére

    Már miért lenne baromság? Olyan rosszul nézett ki az, amit a 9700-es ATI produkált?
    ja

    Kevesebb bittel való számolás kevesebb energiafogyasztást jelent. Mobil eszköznél ez nem elhanyagolható dolog.

    ja, kb 0,1%-al

    Ezeket alá is tudod támasztani? Kíváncsi lennék.
    természetesen. számold ki, hogy hány kódsorba telik megírni benne egy soft távolság és felbontás-independens árnyékolást, egy fénytörést refractionnal, hdr-el, animáció-támogatással, mondjuk úgy, hogy játszhatóan menjen vele legalább 100 millió polygon, legalább kezdetnek mondjuk 100 ezer fényforrásra (ami értelemszerűen nem világítja be mind az egész pályát, csak helszíneket), amelyen mind tetszőlegesen dinamikusak (ez nem jelenti azt, hogy mind mozog, hanem azt, hogy bármikor tetszőlegesen mozoghatnak az enginedben), mindezt körültekintően úgy, hogy képes legyen a kódod leskálázni az előző évtized első harmadában megjelent hardverekhez oly módon, hogy ezeken a hardveren is el tudd indítani úgy, hogy meg is mozduljon néha a kép

    aztán számold ki, hogy mennyi kódsorba kerül ugyanez mondjuk egy saját szoftveres renderereddel (nyilván csak feltételezve azt, hogy meg tudsz egy ilyet írni)

    majd hasonlítsd össze a két produktum végeredményét teljesítményben, minőségben, kompatibilitásban, és hasonlítsd össze a belefektetett időt, és energiát (vagy közvetlenül szólva: pénzt) mindkét esetben

    és lepődj meg nagyon.

  • #28 Pikari veterán Glenda #27
    Új Válasz #28
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Pikari

    veterán

    válasz Glenda #27 üzenetére

    inkább térdelj. a hajlongás károsítja a gerincet.

  • #26 Pikari veterán
    Új Válasz #26
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Pikari

    veterán

    na lássuk:

    Ha maradt volna az FP32-es precizitás, mint követelmény, akkor a piacon fellelhető ultramobil grafikus vezérlők egy része nem felelne meg az elvárásoknak.

    ha már float, 32 bitnél kisebbet támogatni baromság, in my opinion

    A Microsoft az egységesség miatt új formátumokat vezetett be, így mostantól a fejlesztőknek nem kell konkrétan meghatározni a feldolgozás precizitását, de ki kell jelölniük egy minimumszintet.

    már alig várom, hogy a shadow mapok bizonyos driverekkel hirtelen felindulásból fél méteres z hibákat okozzanak, mint a kétezres évek első harmadában

    A lebegőpontos adattípusok szempontjából 10 bit (min10float) vagy 16 bit (min16float) lehet a minimum.

    nem is értem, hogy miféle idióta találta ki ezeket egyáltalán

    rest of the article:
    ilyenkor azért örülök, hogy szoftveres renderelésben utazok már - ez az api is az elődjeihez méltóan használhatatlan, túlbonyolított, alapvető dolgok százezreit nem támogató, inkohézív, inkompatibilis, valóságtól elrugaszkodott, a fejlesztők, a gyártók, és a végfelhasználók igényeit kielégíteni képtelen túlhypeolt romhalmaz

Új hozzászólás Aktív témák

Hirdetés