Crysis 2: Crysis me a river

SHDR

Gullmedlem
#82
Virker ikke akkurat som om Crysis 2 lot seg stanse av DX9, gitt. De har stadig den beste dynamiske lys-og-skygge-bæsjen jeg har sett. Jeg klarer ikke engang huske hva som skal være nytt i DX10 og DX11, annet enn bedre API-er for parallellisert rendring. Hva var egentlig greia med DX10 i første omgang? Hadde egentlig nye funksjoner utenom bedre integrasjon med Windows? Er ting som parallax-mapping umulig i DX9? Er hardware tesselation umulig uten DX11?

Edit: Ok, den changelisten er litt interessant. Displacement mapping? Penumbraer? Ikke at jeg tror jeg kommer til å legge merke til det før titter etter, men hey, skal bli spennende å se hvordan det blir.
 

Agradula

Ridder Jonatann
Medlem av ledelsen
#83
Disse tingene er vel ikke umulig, men da bruker man vel heller OpenGL, fremfor DX9/10/11.
 

Yetipants

Mein Gampf
Medlem av ledelsen
#85
Etter hva jeg har forstått funker DirectX som både inngangsport og stengsel for maskinvaren. Hvis du ikke vil bruke DirectX må du gå for OpenGL, og hvis OpenGL ikke støtter det du vil ha er du shit outta luck siden driveren ikke vil tillate andre forsøk på å få tilgang til GPU-en. Var vel det som var ankepunktet da det ble tatt opp for noen uker siden at enkelte programmerere ville ha muligheten til å progge "direct to metal", noe som selvfølgelig er en hårreisende dårlig ide.
 

SHDR

Gullmedlem
#86
Mhhh, med GPGPU-løsninger som Larrabee (som det kanskje ikke er helt tilfeldig at ikke havnet på markedet) skulle man kunne kode utenfor abstraksjonslag, men de eneste folka jeg noensinne har snakket med som syntes det hørtes ut som en god idé er også folk som synes det virker smart å utvikle sitt eget programmeringsspråk for å kunne gjøre ting på akkurat sin måte, fordi de er gærne jævler som jeg ikke kan fatte at klarer å fungere i et arbeidsmiljø med andre mennesker.

Men det betyr kanskje at man egentlig skriver sin egen "driver", litt à la de hårete protected modesa til DOS i gamle dager? Burde teoretisk sett være mulig å hooke inn i maskinvarekallene til DX eller OGL og så override dem med din egen variant av deres instruksjonssett, så lenge driverarkitekturen er lagt opp for det?

(Men men, bare noe jeg tenkte på, så sånn er det)

Hvis noe er det vel egentlig på høy tid at vi får flere abstraksjonslag, type mer induktive programmeringsspråk hvor man for eksempel definerer logikk mer generelt og så, gjennom testing, eliminere den typen caser du ikke vil at skal oppstå, slik at logikken din "lærer" hvordan den skal oppføre seg, istedet for å kreve at du formulerer ting 100% konkret. Jeg er klar over at enkelte mennesker synes det er ganske enkelt (jeg har blitt nokså flink til det selv etterhvert), men jeg har brukt mange år på det og jeg føler fortsatt jeg er på bleiestadiet.
 

Yetipants

Mein Gampf
Medlem av ledelsen
#89
Det Shdr skrev, basically. De som liker å progge direct to metal er de samme som fikk til ubeskrivelig gloriøse hacks i DOS-æraen, og lagde spill som krevde en bestemt revisjon av VGA-hardware for å kjøre i det hele tatt siden de var avhengige av en bug i ett eller annet. Sånne ting er ikke lenger mulig, og det er prisen vi har betalt for at det stort sett bare er å smelle inn DirectX på en hvilken som helst PC og dra alt av spill så lenge maskinvaren holder. (Liten fotnote: Jeg leste bloggen til kisen hos Remedy som porta Death Rally til Windows; dere som har spilt Death Rally vet hvor imponerende (dvs. ikke kjempe) det så ut originalt, og kisen kunne fortelle lange eventyr om en renderer som var skrevet i haltende assembly og krypterte dataformater hvor nøklene var gått tapt som baserte seg på asynkron overføring mellom prosessor og minne osv. Dette er bare et lite eksempel.)

Ett av de mest fornuftige argumentene jeg så i debatten om DirectX vs. direct to metal var at en av tinga som gjør situasjonen vanskelig for de som vil gå en annen vei ("en annen vei" innebærer også OpenGL), er at duopolet gir faen i alt som ikke heter DirectX siden det er der penga ligger. OpenGL har mange alternative måter å gjøre saker på, men verken Ati eller Nvidia er spesielt interesserte i å legge ressurser i å implementere det i driverne sine siden så få bruker det. OpenGL-folka er vel også en mer ideell organisasjon og har lite å rutte med, kontra Microsoft som selvfølgelig er interessert i å sponse folk som lover at maskinene deres skal kunne levere den beste grafikken.

Og jeg kunne ikke vært mer enig i det siste Shdr skriver. Datamaskiner har lenge vært på et stadium hvor det går an å kompensere for at de er så sabla dumme med ren prosessorkraft, men så godt som ingen er interesserte i å følge det opp, virker det som. Visuelle programmeringsspråk (f.eks.) burde vært et levedyktig alternativ nå. Etter hva jeg leste var Larrabee både kronglete og lite imponerende ytelsesmessig, så appellen ville vel vært rimelig liten hvis det ble lansert. Men: Om noen år kommer den ideen der til å komme tilbake, mer velutviklet og lettere tilgjengelig. Håper jeg.
 

Agradula

Ridder Jonatann
Medlem av ledelsen
#90
Visuelle programmeringsspråk? Gi meg noen eksempler.
Jeg leste at John Carmack er i dialog med forskjellige hardware produsenter for å diskutere hvordan muligheten kan være for å programmere spill og motorer mere direkte mot hardwaren, i stedet for en miks av det og mot operativsystemet. På den måten kunne man sluppet å bruke mye av ressursene på andre ting en spillet. Samtidig, så blir man jo også da mer og mer avhengig av at folk bruker mer og mer lik hardware og da blir jo pcen mer en slags konsoll. Tror jeg da.

edit: eksempler takk, kanskje noen andre enn visual basic, som jeg kun har brukt/sett en gang.
 

SHDR

Gullmedlem
#91
- Scratch (idiotsystem som bare har cred fordi det kom ut av MIT)
- Virtools (idiotsystem som ikke har noen cred overhodet)
- Kismet (teknisk sett scriptespråket til Unreal 3, men også nokså fullstendig på trynet)
- Construct (ikke tæsja, visstnok ganske bra)
- GameSalad (veldig populært, men visstnok også svært begrenset)

Er sikkert en hel haug andre der ute, men jeg husker dem ikke på stående fot.

Strongman har også et, som jeg selvsagt synes er mye kulere enn alle de andre der. Det er iallfall mye, mye enklere enn dem og er laget for å designe spill, ingenting annet.
 

Agradula

Ridder Jonatann
Medlem av ledelsen
#92
Men er ikke litt av ulempen med visuell "koding" at det kan bli jævlig rotete med feilsøking, og at det kan bli ustabilt?
 

SHDR

Gullmedlem
#93
Næh, det avhenger av den underliggende modellen. Scratch, Virtools og Kismet er idiotsystemer som presenterer visuell objekt-orientert programmering ved hjelp av UML, som egentlig er en modelleringsstandard for planlegging av programmeringsprosjekter som av en eller annen pervers grunn har blitt forstått som en del av OOP.

Så lenge koden som ligger under det visuelle abstraksjonslaget er solid (haha) er det ikke noe verre enn scripting, og mye, mye mer brukervennlig. Ustabilt? Nei, avhenger igjen av den underliggende koden. OhMyGame har for eksempel ingen stabilitetsproblemer, ingenting kræsjer noensinne, men det hender ting plutselig begynner å gå satans treigt -- men det er ikke på grunn av den visuelle programmeringen, det er på grunn av spillmotoren.

Skulle egentlig skrive mer, men møte!