- Computex 2025: Már a vízhűtés sem idegen az osztrák hűtőspecialistától
- Computex 2025: Jól sikerült a be quiet! belépője a perifériák világába
- Computex 2025: Nézzük miket mutat idén a DeepCool!
- Comptex 2025: Házak, tápok és kézikonzolok az Antec standján
- Computex 2025: Profi SSD-k, hűtők és más kiegészítők az Adata standján
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Videós, mozgóképes topik
- Home server / házi szerver építése
- Épített vízhűtés (nem kompakt) topic
- Milyen billentyűzetet vegyek?
- Egy nap a TCL-nél: érkeznek az új tévék!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- LG LCD és LED TV-k
- AMD Navi Radeon™ RX 9xxx sorozat
- Melyik tápegységet vegyem?
Új hozzászólás Aktív témák
-
arn
félisten
hat nemtom, te milyen csodahweket es dost hasznaltal...
konkretan nem is volt nagyon erdemes venni jatekokhoz az eredeti blasteren kivul mas hangkartyat, mert jo esellyel futottal bele hibaba. a gus tamogatasarol ne is beszeljunk... a sw mixes verzionak volt, hogy az egyik fele szolt. aztan voltak mindenfele jobb/rosszabb sound libek a jatekokhoz, soknal manualisan kellett javitani a cimeket.
a kezdeti idoben meg a vesak is osszevissza mukodtek, vmelyik gyartoe jobb volt, vmelyik meg szarabb. az univbet erre talaltak ki kesobb (mar ahova kellett, mert az s3e nem volt rossz, de pl a tseng et6000 kartya baromi jo volt, de vhol egy vgas scroll rangatott rajta).
eleve volt olyan programok, amihez ems kellett, mashoz csak xms, etc nem volt olyan config.sys beallitas, amivel minden frankon mukodott.
anno amikor demovetiteseket csinalunk, nem keves munkam volt vele, hogy harom oranyi dosos demo lefusson fagyas es ujrainditas nelkul, egymas utan. pedig aztan a sehol sem tartotta olyan sokaig magat a dos, mint ott. meg 2000ben is jottek dosos cuccok, pedig akkor mar a geforceoknal tartottunk, ami nem volt rossz dxel (mint a riva128, vagy az s3 savage a 3dfx korszakban, amikhez nem tudtak egy epkezlab drvt eszkabalni).
ezek tobbsege ma az oprszeknek es az apiknak koszonhetoen ismeretlen fogalom, csak errol sokan elfeledkeznek.
-
katt777
félisten
Hát én eggyel sem találkoztam. Szarul megírt programok persze akkor is voltak, csak fordított arányban, mint ma. Összeraktam egy 486-os gépet, évekig minden rendben futott rajta, 586-tal, pentiummal hasonló módon, pedig akkor még IBM, Cyrix és egyéb processzorok is voltak. persze nem ártott tudni, melyik mit tud.
opr: Esetleg ennyire a dolgok mögé látok, éppen elég ideig dolgoztam benne. No de mindegy, hiába itt a vita, úgyis az lesz, amit a nagy gyártók akarnak. A lényeg, hogy ugyanaz marad, mint az elmúlt 20 évben:
Nyomják a kamu marketinget ezerrel, miközben mindegyik cég alapból fúrja az összes tervet (és a többiek fejlesztését), hogy ő arassa le a hasznot. A végfelhasználó továbbra is szívni fog.
-
Hiftu
senior tag
Hogyan lehet majd biztosítani az eltérő architektúrák különböző verzióinak támogatását? A GCN esetében is volt róla szó, hogy 1.0-ra meg 1.1-re is külön kell optimalizálni. Nem fog ez végül elfeledett verziókat eredményezni? Hogyan lehet majd reviewzni/tesztelni egy játékot ha hasonló hw-n is esetleg eltérően viselkedik?
-
arn
félisten
A szarul fut, az viszonylagos... Idealis esetben Most lesz egy ugras sebessegben, aztan utana hova? Nem fognak utana is ugrani, mert a hw veges, es beallitani ott is be lehet, hogy hasonloan "lassu" legyen.
Amirol nem tud az ember, az nem faj. Szvsz tenni fognak magasrol a nem reprezentativ hwken kivuli vasakra.
-
sb
veterán
Nem megoldás, mert attól a másik sz*ra marad amit senki nem szeret eltakarítani.
Marad az egymásra mutogatás és a költségcsökkentés jegyében abban bizakodás, hogy a másik majd megoldja.Szerintem jobb helyen van ez az app-fejlesztőknél. Alapvetően az ő érdekük, hogy jól és több hw-n fusson a programjuk. Írják meg ők. Úgy.
Ha nem akkor meg náluk csapódik majd le a (negatív) eredménye.
Ez így normális szerintem. -
Vladi
nagyúr
A fekete dobozra meg szerintem megoldás a nyílt forrás. Hmm... Mit kapok ezért.
De mintha lett volna erről cikk mostanában. Nyílt driver + nyílt játékmotor. X számú játékmotor, ami töredéke a mainak, hardver fejlesztők és játékfejlesztő cégek szponzoráljká, de legalább meg van írva tisztességesen. A játkstúdió meg ezekre húzza rá a saját "bőrét". Maga a játék fizetős, de nyílt motoron fut. Hátnem?
-
Vladi
nagyúr
"tűnjön el a hagyományos értelemben vett grafikus eszközillesztő, hogy a fejlesztő végre maga is láthassa mi folyik az alsóbb rétegekben, beleértve a hardvert."
Ühüm. Merő kupleráj a játék motorja, most jól a hardverben is csinálhatják a baromkodásukat. Szupi.
"hiszen az adott fejlesztő direkten átveszi a grafikus meghajtó feladatait"
Ettől félek én. Lesz olyan stabilitás, hogy ihaj. w95 egy merő unix lesz hozzájuk képst.
Egyébként én már régóta mantrázom, hogy a szoftver szar. A hardver már 10 éve nagyonelég, de a szoft egyre rosszabb.
-
sb
veterán
Bugot javítottak, de csak amit tudtak. Arra volt elég, hogy szarul fusson minden i7-en is.
Most legalább az esély megvan, hogy a fejlesztő megcsinálja jól... vagy nem. És akkor ugyanott tartunk, mint eddig.Szerintem hibás hozzáállás ez a játékfejlesztő+driverfejlesztő felállás amikor mindketten egymás
sz*rátfekete dobozát akarják javítgatni. Elvi szinten sem lehetséges, hogy ebből bármi jó szülessen. A konkrét példát meg látjuk az utóbbi 5-10 évből. -
kisfurko
senior tag
Pedig igaza van. Grafika programozásban baromira nincsenek semmilyen komponensek, meg mindenféle csoda dolog. Van az API és slussz. Létrehozol erőforrásokat, piszkálod azokat, állapotokat állítasz be a rajzolás előtt, meg rajzolsz. Viszont nem lehet mindent tetszőlegesen kombinálni. Pl. nem rajzolhatsz lockolt pufferből, bizonyos beállítások nem kompatibilisek egymással a textúra-mintavételezőben, a ROP-ban stb. Ugyanígy a shader program sem írhat akárhogy, vagy olvashat máshogyan, mint ahogyan deklarálva van a bemenet. Figyelni kell, hogy az előző fokozatból jövő adatok tényleg úgy nézzenek ki, mint ami kell. Amikor sokezer dolgot rajzolsz ki, majd minden dologhoz egyedi textúra-mintavételező, ROP és egyéb kombinációval, és mindez képenként változik, na akkor teszteljed le. A DirectX runtime jelenti az összes érvénytelen kombinációt, no de csak debugnál. Ekkor, természetesen egészen más sebességgel fut, mint release libraryvel. Csomó időbe kerül, amíg rájössz, hogyan lehet reprodukálni debug alatt, ha rájössz. Szóval totál kiszámíthatatlan. Elég egyszer egy rossz kombinációt beadni, a legközelebbi device resetig jöhetnek a mellékhatások. Ha szerencséd van, a következő state change elmúlasztja. Hidd el, a legjobbaknál is becsúszik egy ilyen hiba.
Beszélsz itt automatizált tesztekről egy interaktív programnál...
Aztán vegyük a teljesítményt. Kb. nulla információ van arról, hogy milyen állapotváltás mennyi időt igényel, vagy hogy mi az, amit még meg tudsz változtatni némi késleltetés nélkül. Többnyire próbálgatással deríted ki, hogy milyen paraméterek alapján sorrendezd a rajzolásokat, ami persze egy másik kártyán megint más lehet. Aztán néha kiderül, hogy ami az API leírása szerint gyorsabb lenne, az nem gyorsabb
Aztán vannak olyan dolgok is, hogy a gyártó profilere egyszerűen szétfagy, pedig a saját profiler driverével megy. Úgy igen nehéz teljesítményre gyúrni... -
#18
antikomcsi
veterán
Menthirist
#16
antikomcsi
veterán
válasz
Menthirist
#16
üzenetére
Biztos beljebb vették közben a margót!
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#16
Menthirist
veterán
"A DirectX 9-ben a Clear függvény kezelése majdnem százezer sor csak arra vonatkozóan, hogy a meghajtó hogyan válaszoljon a parancsra, "
Ez amúgy csak ezer a hivatalos cikk szerint:
The backing function for Clear in D3D 9 was close to a thousand lines of just logic dealing with how exactly to respond to the command. -
konkrét példákat hozott az ipse a cikk szerint, milyen hibáik vannak. api szabványok megsértése, shaderek nem megfelelő implementációja miatti szükségtelen többletterhelés. ez azért némiképpen komolyabb, mintsem egy nagyon komplex programról elmondani, hogy egyes, előfordulási valószínűségét tekintve marginális helyzetekben vektorhibák vannak a megjelenített felületen.
-
-
katt777
félisten
válasz
Angel1981
#12
üzenetére
Az evolúció kifejezést én nem használnám, mert ha az igazi így zajlott volna, már rég kihalt volna a Föld (bár az emberiség kollektív iq-ját figyelve vannak arra utaló jelek, hogy így lesz).
Régen pont az volt, hogy felraktad a DOS-t, nem szarakodott 300 rezidens program a háttérben, amiből 280 fölöslegesen fut. Akkor a hardvert programozták, gépi kódban (magam is tanultam), ment is minden, mint a karikacsapás, mert ha elb.sztad a kódot, nem futott. Csak mint azt a nagy cégek elismerték, ezek a programozók már rég nem dolgoznak (nem kellett a szaktudásuk az API-s programozás korában), és az új hardvereken nem is tudnának már (vagy csak ezt mondják, mert nem fizetnék meg őket). No és persze roppant kevesen vannak.
Ja és persze mivel anno mindent mindennel egybe lehetett építeni, muszáj is volt rendesen megírni a programokat, mert ha pl. AMD kártyán (vagy procin) nem ment volna az, ami a többin igen, az komoly következményekkel járt volna. No de minden cégnek külön út kellett, ehhez meg a kizárólag a minél kisebb (de mindig) rossz irányába fejleszthető univerzális API, adta magát a dolog, maguknak csinálták azt a katyvaszt, amelyből ma nem tudnak kilábalni. -
katt777
félisten
Hát, ezért aztán megérte nyomkodni a billentyűzetet!
Minden épelméjű felhasználó a Windows 95 tudja, hogy minden szoftver hibás (legyünk jóindulatúak: csak azok, amelyekhez javítást adnak ki ), előtte frankón futott minden 5-féle procin (amelyeket akár 1 alaplapban is lehetett cserélgetni) és 10 féle VGA kártyán ugyanúgy, ha nem több volt, drivereket sem kellett évekig frissíteni. Tudom sajnálni, hogy kezdetnek elszarták a hardvereket.A programozók mindent, mindig meg tudnak magyarázni, csak el nem ismeri egyik sem, hogy szar munkát végzett, hiába bizonyítja ezt egyértelműen munkájának eredménye. Nem mintha felhasználóként érdekelne, ki miért nem végezte el azt a munkát, amiért egyébként mi fizetünk, többségünk mégis jóindulatú elnézéssel nyugtázza a dolgot, pedig a saját cégéből nyilván rögtön kirúgná az illetőt (vagy addig ütné, amíg el nem végzi a munkáját (némelyik játék láttán legalábbis erős késztetést érez erre az ember).
-
Cathfaern
nagyúr
"Persze más kérdés, hogy mi lesz a nem techbuzi fejlesztőkkel, mert nekik az új api inkább bosszúságot okoz."
Nem fognak közvetlenül 3D-s grafikát programozni, hanem használnak olyan platformokat, mint pl. a Unity. Ugye ezek mára gyakorlatilag már ingyenesek, bizonyos bevétel felett kérnek csak részesedést, így ideális kis költségvetésű játékokhoz. -
Goose-T
veterán
A játékfejlesztő játékot fog fejleszteni ezután is, továbbra sem kell polihisztornak lennie. A játékmotor-fejlesztők kapnak több teret ezután az optimalizálásra - arra az optimalizálásra, amit eddig a driverfejlesztők végeztek nagyon nem hatékonyan és utólag dolgozva (új driverrel végre +10FPS x játékban, meg ilyesmik). Most végre a helyére kerülnek a feladatok:
* driverfejlesztők: összekapcsolják az alacsony szintű API-t a hardverrel
* motorfejlesztők: hatékonyan optimalizálják a saját, jól ismert játékmotorjukat a különböző architektúrákra az alacsony szintű API lehetőségeinek kiaknázásával
* játékfejlesztők: na ezek ezután is tök ugyanazt fogják csinálni, mint eddig, fejlesztik a játékot a választott motorra. -
Szerintem az a gond, hogy a grafikus driverek mára egy-egy hatalmas bloatware-ré nőtték ki magukat. De ez nem a fejlesztők, hanem a hagyományos grafikus api-k koncepciójának hibája, hogy mindent meg akar csinálni helyetted, s ezeket a driverbe kell implementálni. Ugyan egy egyszeri fejlesztőnek nagyon jól jön az egyszerűen programozható felület, s nem is érdekli mi van mögötte (bloatware), de egy techbuzi stúdiónak ez korlátozó tényező, mert egy fekete dobozt nagyon nehéz debuggolni vagy rájönni hogy hol van a szűk keresztmetszet teljesítményben. Illetve ott vannak a funkcióbeli hiányosságok is, lásd használható multithreading CPU-ra.
A techbuzik problémáinak megoldására a driverben a grafikus api rétegét radikálisan le kell vékonyítani, s fejlesztő kezébe adni a kontrollt. Ezzel kvázi drivert írnak a fejlesztők, de azért ez nem teljesen igaz, hisz a driver megmarad, csak alacsonyabb szintű a hozzáférés.
A "hibás játék" szerintem szimplán a jelenleg elterjedt grafikus api-k problémáira utal.
Persze más kérdés, hogy mi lesz a nem techbuzi fejlesztőkkel, mert nekik az új api inkább bosszúságot okoz.
-
Duck663
őstag
"Ezért hatalmas ötlet az új generációs API-kban, hogy tűnjön el a hagyományos értelemben vett grafikus eszközillesztő, hogy a fejlesztő végre maga is láthassa mi folyik az alsóbb rétegekben, beleértve a hardvert."
Igen ám, de ehhez dokumentálni is kellene a hardvereket!
-
arn
félisten
de legalabb eddig vki vette a faradsagot, es javitotta a bugot - de ezutan hol lesz egy jatekfejleszto erdeke, hogy vmi regebbi vason hibamentesen fusson vmi? vagy ok fognak beleoszulni, vagy tesznek ra majd magasrol.
aztan lehet a gyartokat fikazni, mert a usereknek nem fog majd leesni, hogy forduljanak a jatekfejlesztohoz, mert megszoktak, hogy jott a javitas drv oldalrol.
-
"Az új API-kra egyébként nehezebb lesz majd kódolni, hiszen az adott fejlesztő direkten átveszi a grafikus meghajtó feladatait, az viszont még kérdéses, hogy mennyivel."
Ez a lényeg. A hibás dologgal, meg azzal, hogy egy fejlesztő beszél, csak arra megy ki az egész, hogy kinek a térfelén pattogjon a labda. A játékfejlesztő nem drivert ír, hanem játékot. Adjuk oda neki az oprendszert is és minden meg lesz oldva... vagy nem. Nem lehet polihisztorságot elvárni a fejlesztőktől sem és egymást hibáztatni sem túl szép.
"Az első dolog, amit megtanult, hogy szinte mindegyik játék hibás"
Örömteli. Minden játék/szoftver hibás? Persze. Aki mást mond, az nem ért hozzá. Na, de mi számít hibának és melyik rétegben, komponensben? Funkcionális vagy teljesítménybeli? Kritikus vagy sem? Esetleg by design? Lehet, hogy rossz a követelmény? Stb. Ez így elég fura kijelentés. Ráadásul nagyon marketingszagú az egész dolog. Ezek nem belsős infók, simán csak a nyilvánvaló és vélekedések keverése - hogy átpasszolják a labdát másoknak.
Másfelől viszont a tesztelésen múlik a legtöbb, de nem azokon, akik a már (fél)kész játékot nyomogatják, hanem automatizált teszteken. Ezek gyakran elmaradnak mind a driver, mind a játékgyártók oldalán. Az indok: pénz, idő, energia.
az nem is tolom 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Minden épelméjű felhasználó a Windows 95 tudja, hogy minden szoftver hibás (legyünk jóindulatúak: csak azok, amelyekhez javítást adnak ki 
Új hozzászólás Aktív témák
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- E-roller topik
- Macska topik
- Videós, mozgóképes topik
- Max
- Apple iPhone 16 Pro - rutinvizsga
- Home server / házi szerver építése
- Kínai és egyéb olcsó órák topikja
- Épített vízhűtés (nem kompakt) topic
- Milyen billentyűzetet vegyek?
- További aktív témák...
- ÚJ, 27% ASUS TUF Gaming RTX 5090 32GB GDDR7 Videokártya! BeszámítOK
- BESZÁMÍTÁS! ASRock FORMULA OC RX 6900XT 16GB videokártya garanciával hibátlan működéssel
- Powercolor Red Devil 6700XT
- BESZÁMÍTÁS! ASUS TURBO RTX 3090 24GB GDDR6X videokártya garanciával hibátlan működéssel
- GIGABYTE RX 6600 XT 8GB GDDR6 EAGLE Eladó!
- Azonnali készpénzes Intel i3 i5 i7 i9 12/13/14 gen processzor felvásárlás személyesen / csomagküldés
- BESZÁMÍTÁS! SAPPHIRE VEGA 64 8GB HBM2 videokártya garanciával hibátlan működéssel
- Apple iPhone 11 Pro 64GB, Kártyafüggetlen, 1 Év Garanciával
- LG 42C3 - 42" OLED EVO - 4K 120Hz 0.1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen6 CPU
- IKEA (HAVREHOJ) tablet vagy laptop tartó
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest