Jump to content

TheMaister

Medlemmer
  • Content Count

    1454
  • Joined

  • Last visited

Community Reputation

22 :)
  1. Spilte inn et nytt stykke http://themaister.net/music/tenet_pt2.flac
  2. Ja, det er et godt poeng. Å lage en GL3+ contekst i rein Win32/WGL er ganske knot (bakoverkompatibilitet hurra <_<), og litt knot i X11, men er jo det man har wrapper-biblioteker for egentlig. D3D kan implementere sånt direkte siden det er 0 krav om portabilitet til sære platformer så det hjelper jo på. Å få til multisampling er ganske enkelt når man først har fått 3.x contexten i gang. To linjer i attrib-arrayen eller noe sånt. Et av de største problemene jeg har med D3D er hvordan vertex streams blir håndtert og binding med buffere. GL gjør det veldig lett med attribarrays, der man kan gjøre lookups ved navn, og binde direkte til id-en man får gitt, men i D3D må alt bakes inn i definisjon på forhånd, og det er ikke spesielt moro å ha med å gjøre hvis shadere plasserer argumentene sine i forskjellig rekkefølge enn andre, osv. I dette tilfellet må man begynne med reflection på shaderene, og da gir jeg bare opp. D3D10+ er enda mer plagsom enn det igjen ...
  3. Har ikke jobbet så forferdelig mye med D3D at det gjør noe, men føler at moderne GL (3.x+) og D3D10+ er i bunn og grunn veldig likt. Last inn shadere, bind teksturer til units, vertex buffere osv, og rendre diverse former ... Er mest syntaksforskjeller det går på, der D3D10 er mye mer "verbose", men feilsjekkingen er mer robust. Største forskjellen er kanskje GLSL og HLSL.
  4. Hva er det du tenker her? Er planen å lese rå pikseldata fra backbufferen (noe ala FRAPS), eller logge OpenGL-kall? Hvis førstnevnte bør du lete opp LD_PRELOAD (Linux) eller DLL-injection (Windows), samt glReadPixels() som kan lese framebuffer-data fra GPUen. Hvis sistnevnte er det mulig å reimplementere hele opengl biblioteket i form av stubs (å autogenerere et slik bibliotek i f.eks Python høres ut som et greit prosjekt) som logger, og sender kallene videre til faktiske OpenGL.
  5. Vent, man oppgir Social Security Number til spillselskaper? Eller for å logge seg på nett overhodet? Skal man tro http://en.wikipedia.org/wiki/Resident_registration_number virker det som at man må gi SSN til enkelte spillselskaper ja.
  6. Er ikke så lett i Sør-Korea. IIRC kreves Social Security Number for online ting og tang.
  7. Komponert et lite piano-stykke, så kunne jo være greit å poste det her http://themaister.net/music/tenet.flac
  8. Sant nok, men de skjer! Hadde en bug selv der en bruker ville allokere 8GB, og på et stadie brukte jeg unsigned istedenfor size_t. Er enda mer forsiktig med å bruke size_t nå.
  9. Fra tid til annen snubler jeg over slik kode: void *ptr = somedata; unsigned int bar = (unsigned int)ptr; .__. Morro å finne slike bugs klokka 2 på natta, ja
  10. long long må være minst 64-bit, og større eller like stor som long. <stdint.h> er her for en grunn. Kode som ikke bruker int/uint*_t (eller tilsvarende) for størrelser som skal ha et visst antall bytes er broken. Har vært borti alt for mange tilfeller der kode har gått ut i fra at long er 32-bit. Dette ser jeg omtrent bare i Windows-kode (morsomt å porte slik kode), så kan være noe der at MSVC ikke fikk stdint.h før i 2010! Grunnen til at C er veldig vag på dette med størrelser er for at man skal kunne implementere C effektivt på veldig merkelige systemer. Husk at CHAR_BIT ikke _må_ være 8. Noen maskiner som har 19-bit ord, osv, men det ser man nok ganske sjeldent i dag (heldigvis). Hver gang man skriver short eller long bør man tenke seg godt om.
  11. I C betyr pointer-alias at en blokk med minne blir pekt på av to eller flere pekere av ikke-kompatible typer. Det er skummelt og kan forårsake "morsomme" bugs. unsigned int *foo; er en peker som peker på unsigned int. Når da pekeren blir castet til unsigned long*, en ikke kompatibel type, har vi pointer-alias. Hva som skjer da er ikke definert av C-standarden. Typisk går det bra, men har vært borti flere tilfeller der koden ikke virker i det hele tatt med kraftig optimisering.
  12. double -> long er ikke akkurat problemet her, pointer-alias er et ganske stort problem.
  13. Bare å begynne å løpe. Koden er ikke lovlig i det hele tatt og vil muligens kræsje hardt. Vel, *(unsigned long*)foo = bar; betyr at foo castes til en peker til unsigned long, der innholdet av hva foo peker på blir satt til bar, som om det var en long, og ikke unsigned int. En annen måte å skrive det på er: unsigned long *foo_long = (unsigned long*)foo; // OBSOBSOBSOBSOBS skummelt! *foo_long = bar; Koden vil sikkert kjøre fint på Windows, men vil ikke fungere som planlagt på Linux og OSX 64-bit er long er 64-bit og ikke 32-bit. (Hvorfor i all verden skriver folk kode som dette? Vi er i 2011, ikke 1999 ... <_<)
  14. Sitter akkurat nå og koder i C ... på et Unix-basert system. R.I.P. dmr = realloc(dmr, sizeof(Greatness));
  15. Hmm, gjerne finn et sitat om du kan, så er det lettere å se om det er synsing. Nå bruker ikke Rage på PC Direct3D i det hele tatt. Kom tilfeldigvis over intervjuet http://www.pcper.com/reviews/Editorial/John-Carmack-Interview-GPU-Race-Intel-Graphics-Ray-Tracing-Voxels-and-more
×
×
  • Create New...