Far Cry strul

[RN]

PPS Klart du ska en poäng också för ditt besvär - och att det här innebär att "problemet" nu ska vara avklarat så det inte blir någon annans huvudvärk... ;-)

Det tackar jag för! :-) Men Far Cry ger tyvärr fortfarande anledning till endel huvudvärk. Igår uppstod nämligen ett konstigt fenomen som jag tycker du bör få se. Har därför tagit fyra nya skärmdumpar som visar denna lite skrämmande sak.

 

Drivarmenyn har haft inställningen flersamplad genomskinlighetskantutjämning och system.cfg inställningen r_HDRRendering = "7".

 

Två olika vyer med två bilder vardera visas. Ena bilden hade inställningen 4xAA från drivarens menyer och den andra, exakt samma, 4xAA i stället från spelets menyer:

http://public.fotki.com/RnRising/farcry_hdraa/

 

Frågan uppstår nu: vad är problemet? Spelet, patch 1.40, drivaren, själva Nvidiakortet eller vad..? Kanske drog jag en förhastad slutsats som tyckte man kunde döda myten om Nvidia och HDR+AA. Eller kanske problemet inte är själva kortet utan något annat – varför går det bra att tvinga fram AA från drivarmenyn men inte spelet?! Det här verkar uppenbarligen vara ett inte alldeles enkelt dilemma. Men man kanske ska komma ihåg också att 1.40 faktiskt är en beta, som dessutom blev läckt..!

 

Kommer också en ny och förhoppningsvis sista film med drivarinställningen 2xQ-AA samt MTAA (tänkte bara om Nvidias Quincunx kanske underlättar nånting för kortet).

 

Ev AA är så gott som omöjligt att upptäcka på filmen, men iaf HDR. Ville också visa det läckra fenomenet från mappen Dam (tror jag det var) då luften riktigt dallrar av hettan från lavan, och hur synfältet periodvis begränsas av detta genom "blinkande" grenar på träden (alltså inget grafikfel, det ska se ut så). :-)

 

P.S. Publika länkar till bilderna på Fotki hittade jag igår under knappen Share photo men idag fanns där inga länkar alls. ;-)

[inlägget ändrat 2006-08-17 11:51:22 av RN]

[Stålis]

Det är inte slut förrän den tjocka damen sjunger.

 

Ja du, om jag visste svaret. :-?

 

Men förmodligen verkar AA i drivrutinerna på en annan nivå än vad spelet gör. Nu har jag inte exakt i huvudet var jag läste varför AA och OpenEXR HDR inte skulle kunna fungera ihop på Nvidia, men det var i den allra sista delen i hanteringen av texturerna i grafikkortets uppbyggnad problemet uppstod.

 

Där blev man tvungen att välja mellan antingen MSAA eller HDR, det gick alltså inte att få båda. Rent spontant tycker jag då att man kanske skulle kunna "köra ett varv till" och komplettera andra varvet. Kanske kan man göra det, men då faller ju poängen med MSAA eftersom det ska vara en snabbare approximation av SSAA, och en sådan metod skulle förmodligen kräva mer resurser i anspråk, och då är kanske SSAA ändå att föredra (om det nu ens går att genomföra en sån loop). En av fördelarna med DirectX 10-korten är som jag förstått det just att det ska gå att loopa texturer i delar av grafikpipelinen, vilket ju isf skulle innebära en lösning på många liknande problem.

 

Atis lösning är inte universellt bra, den måste tillämpas på alla texturer. GRAW har ju inte HDR och AA för varken Ati eller Nvidia, och jag tolkade det som att det spelets inre uppbyggnad gjorde att man isf var tvungen att lägga AA på en massa ställen där det inte behövdes, vilket skulle göra att det i praktiken blev så långsamt att det inte var värt det, även om det var tekniskt möjligt.

 

Tidigare fick jag det här svaret av DocSEAL:

HDR and AA have always "worked" together with NVIDIA cards since patch 1.2. The problem is they conflict on graphics card subsystem and cause very bad anomalies in the game. You'll get very bad texturing, ripping, see through walls, fall through ground, etc.

Det är väl det resultatet som man ser på dina bilder. Grafikkortet blir förvirrat och texturerna blir korrupta i hanteringen när de körs genom spelet. Kanske är drivrutinerna lite "smartare" och kan plocka ut kanterna efteråt? I princip, eftersom det som man ser på skärmen är en 2D-bild, skulle det vara möjligt för en algoritm att leta upp kanterna i bildytan och utföra kantutjämning innan den lägger ut bilden, men det skulle innebära en massa tidskrävande avancerad bildhantering att leta efter kanter över hela ytan. Det är ju lite enklare när man har texturerna och vet var kanterna är, och bara göra det lokalt. Men just när man kör genomskinlighetskantutjämning blir man ändå tvungen att köra testet över hela den texturen, eftersom den är genomskinlig, så det skulle kunna vara en väg att gå... Fast du körde ju på flersamplad? Då hamnar man ju i samma problem som tidigare, och den teorin hade varit troligare om du hade kört på supersamplad genomskinlighetskantutjämning. Fast även i det fallet hade det ju bara handlat om att gå över de genomskinliga strukturerna och inte hela bilden. Som sagt, jag vet inte. Du får skriva till Nvidia och fråga! :-)

 

/ m

[inlägget ändrat 2006-08-18 13:02:43 av Stålis]

[RN]

Tidigare fick jag det här svaret av DocSEAL:

 

HDR and AA have always "worked" together with NVIDIA cards since patch 1.2. The problem is they conflict on graphics card subsystem and cause very bad anomalies in the game. You'll get very bad texturing, ripping, see through walls, fall through ground, etc.

Jo, jag har faktiskt redan läst det där uttalandet för några dar sen, steelmartin :-), och måste säga att det förbryllade mig endel. Brukar normalt inte hänga till på crymodforumet så jag "känner inte till folket" där alls, men undrade iaf om DocSEAL baserade sitt påstående på patch 1.2 (vilket jag iofs betvivlar) som ju drogs tillbaka bl a på grund av väldiga kompatibilitetsproblem med viss hårdvara. Men så uppstod som du såg ett dylikt fenomen på min dator...

 

Har installerat om Far Cry och struntat i betan 1.4 denna gång – den verkar vara väldigt buggig faktiskt (upptäckte åter en bugg igår; det går öht inte att avlossa raketgeväret). Eventuellt testar jag HDR+AA lite till med både 32-bit 1.33 och 64-bit 1.32, och då med t ex supersamplad transparency-AA...

 

Prövade iaf samma sak på lillebrorsans 6800GT också (XP 32-bit, AMD64 ECU, patch 1.4) och exakt samma fenomen uppstod även på hans dator – grafikfel med AA ifrån spelmenyn men inte då jag ställde 2xQ-AA från drivarmenyn (och r_HDRRendering = "5"). Jag hade väldigt gärna lagt vantarna på ett nyare Ati-kort för att testa exakt samma sak.

 

GRAW har ju inte HDR och AA för varken Ati eller Nvidia...

När du nämnde GRAW kom jag att tänka på Ageia och PhysX-kortet. Får se hur det kommer gå för dem..? Själv hade jag förmodligen hellre lagt de ca 3000 kronorna på ytterligare ett grafikkort för att få mer muskler för Havok-FX, då ena kortet t ex skulle kunna sköta renderingen av bilden och det andra fysikberäkningarna (Havok-FX kan ju nyttja GPU:n i såväl Ati- som Nvidakort och denna är oerhört mkt snabbare att räkna på fysiken än datorns processor).

 

EDIT:

En tanke slog mig just angående patch 1.4. Apropå vad som står längre ner här...

 

http://en.wikipedia.org/wiki/High_dynamic_range_rendering

Shader Model 2.0 HDR

Far Cry

(SM 2.0 HDR patch soon)

 

...så började jag fundera på ifall det i själva verket är 1.4 som i så fall skulle vara denna SM2.0/HDR-patch(?) Kan tankas från t ex Gamespot där det står så här om den:

"This beta patch for FarCry adds HD support, but only works with GeForce series 6 and 7 and limited ATI cards."

http://www.gamespot.com/pages/gamespace/download.php?pid=371314&sid=6141708&mode=patches

 

Vet dock inte hur pass väl den infon stämmer. Den medföljande Read Me-filen "How to enable FSAA+HDR for Ati X1K owners" innehåller nämligen inte ett ord om Nvidiakort (vilka fick HDR vid 1.3 (eg 1.2):

[log]To enable HDR+FSAA...

 

 

 

1) Copy/overwrite the files to your existing Farcry game.

 

 

2) Start the game and Select your desired FSAA mode (2-4-6) in the Farcry video menu.

 

 

3) Go to the console (~) and...

 

- type \r_FSAA 2

 

press Enter

 

- type \r_HDRRendering 1-11 ("7" looks best, "2" is also nice and has better performance)

 

again press Enter, leave the console (~) and enjoy!!!

 

 

 

 

 

Tip: for best performance in outside levels, don't change your "e_vegetation_sprites_distance_ratio" value, leave it

at default = "1.000000"

 

 

 

Issue's with this patch; this is a pre-release beta patch, if you find any issue's you

can't hold anyone responsible for this. Use it at your own risk, no support!!![/log]

Fast nu hör det ju också till saken att "Ati X1K" faktiskt stödjer SM3.0, medan min stilla undran som sagt var ifall patch 1.4 egentligen var denna tilltänkta SM2.0/HDR-patch..! :-/ (exempelvis fick ju SC:CT SM2.0/HDR fr o m dess patch 1.4 för bl a Radeon X800-serien)

 

Tror att jag ska forska vidare i det här vid mån av tid...

[inlägget ändrat 2006-08-18 20:46:12 av RN]

[Stålis]

Intressant fynd! :-) Om det handlar om en SM 2.0-tillämpning i patchen skulle det förklara en del. Och eftersom patchen blev läckt kan det t ex vara så att informationen som gavs koncentrerades på Ati iom att de inte hade HDR tidigare. Fast Atis SM 3.0-kort fanns ju ute när patchen läcktes? Hoppas att den som skrev det är mer insatt i vad som verkligen gäller.

 

Angående fysikkort läste jag en lite halvdan artikel på THG (tror jag), som berörde fysik i spel, men den utmynnade iaf i den vettiga (och uppenbara, tycker jag) slutsatsen att fysik i spel inte är detsamma som fysik i verkligheten. Det handlar om en simulering, och någonstans måste man dra gränsen mellan "verklig" fysik och spelfysik. Allt går inte att göra.

 

Och ytterligare någonannanstans läste jag att Ageia hade möjlighet till en djupare, "sannare", fysikimplementering än vad som skulle vara möjligt med fysik genom grafikkortet, som sas bara var av mer kosmetisk typ. Nu vet jag inte hur sant det är, men utmaningen för utvecklarna kommer nog att bli att hitta den där balansen mellan realism och kosmetika. En spelvärld är ett modellbygge och en simulering, och precis som i alla modellbyggen måste man göra förenklingar och approximationer. Det handlar om att ge en illusion.

 

Samma inställning gavs det uttryck för i en post på ett utvecklarforum för spel (som jag hittade när jag letade runt efter lösningar på den "suddiga" texturen). Där påpekade en kille:

As I said at the start, it's all too easy to get caught up in way we're used to using CG. We're all guilty of it. Just remember to take a step back every so often and realize that our job really revolves around faking things

 

Jag kan se uppenbara svårigheter med fysik vid t ex onlinespel. Att ställa ner grafiken och detaljerna är en sak, men hur ställer man ner fysiken, speciellt om den är tänkt att påverka spelet? Jag tror att vi där får leva med den mer kosmetiska sidan av fysiken, dvs mer grejer som flyger i luften vid häftigare explosioner, tyg som fladdrar i vinden etc, dvs saker som i princip bara syns på den lokala datorn och inte har någon påverkan på spelet, medan den mer sanna, mer djupgående fysiken som förändrar spelet bara kommer att kunna tillämpas i singleplayer. Iaf än på ett tag, innan någon sorts gemensam grundplattform, eller standard att "skala" fysik, uppstått.

 

Fast, som sagt, jag ser fram emot att bli lurad av mer trovärdiga illusioner! :-)

 

 

/ m

 

PS Och jo, steelmartin fick det bli en gång i tiden, steelis låter ju inte lika bra... :-)

 

[RN]

Fast Atis SM 3.0-kort fanns ju ute när patchen läcktes?

Ja, iaf som jag minns... och dessutom så varför skulle det inte funka med HDR på Ati X1K-kort redan fr o m patch 1.3 förresten? Snart köper jag ett j-a kort bara för jag vill veta! ;-) Patch 1.32 har ju nämligen buggfixen "Fixed a Shader Model 3.0 issue that caused graphics corruption on new ATI hardware", så eftersom SM 3.0 funkar utgår jag ifrån att även HDR gör det:

[log]Patch 1.33 change log

 

* This patch supports 32 bit only.

* This patch will update versions 1.31 and 1.32 to Far Cry 1.33.

* Far Cry patch 1.33 contains all the fixes found in 1.32.

* Fixed issue with extended characters in players names causing server crashes.

* Included version checking so that only 1.33 clients can connect to 1.33 servers.

* Resolved some online cheating issues.

 

 

Patch 1.32 change log

 

* Fixed a Shader Model 3.0 issue that caused graphics corruption on new ATI hardware.

* Set the game to detect nVidia hardware to avoid shaders being compiled at run time.

* Recompiled the 32bit version with a different version of STL to address some server slowdowns.

 

 

Patch 1.31 change log

 

* Fixed an exploit where going prone while carrying scoped weapons disables weapon sway.

 

 

Patch 1.3 change log

 

* Fixed a crash with the ForkLift when loading some levels.

* Fixed a bug that prevented levels from loading after saving in a previous level.

* Returned surround 5.1 sound option to the menu.

* Fixed a mounted weapon traverse problem.

* Fixed problems related to shaders1.pak and scripts1.pak not being removed on installation of the patch.

* Fixed a delay relating to tagging enemies in binocular mode.

* Normal Map Compression. Requirements: NVidia: Geforce FX Family or better, ATI: x800 card or better. This feature is disabled by default. To enable it, type r_TexNormalMapCompressed 1 in the console after loading a level. Enabling this feature during the game may take some time - the PC may appear to freeze. This variable will not be saved when restarting the game. Enabling normal map compression will have prolonged execution the first time running through a level due to initial compression phase occurring in real time through the level. Subsequent reloads of the same level will yield better performance and therefore we recommend that you run any benchmark twice and to take the second of the two runs for benchmarking purposes since this most closely represents the usual user experience.

* SM 3.0 and SM 2.0x are now enabled by default when graphics settings are set to ‘Very High’. To see performance increases you must have Direct X 9.0c installed.

* Improved tangent-space calculation to improve bumpmap quality.

* Anisotropic filtering disabled for some textures (light-maps, several lookup textures, fall-off maps) for increased performance.

* When attempting to connect to PunkBuster regulated servers, make sure you are not running with –DEVMODE enabled. Run the Farcry.exe itself (not a shortcut) if you are unsure.

* If you are kicked from a PunkBuster enabled server with the reason “No packet flow”, make sure the Windows XP internal firewall is disabled.

* Improved syncronization in multiplayer.

* Fixed bug in leaning with different player classes.

* Fixed an invisible wall exploit in mp_freighter.

* Please ensure you have your graphics cards latest drivers installed.

 

Patch 1.2 change log

 

Current changes:

 

* Made the run speed about 15% faster

* Made sprint last 30% longer

* Adjusted damage to vehicles

 

(vehicles now survive longer in multiplayer and behave consistently between weapon damage types) Bullet damage can be disabled by “g_vehicleBulletDamage” cvar: 0 = no bullet damage (default), 1 = bullet damage; this works only in MP.

MP vehicles can get the same damage from every kind of bullet (no distinction between sniper rifle and the deagle), this value is set by ‘dmgBulletMP’ variable inside ‘DamageParams’ table of the vehicle.

 

-buggy, humvee and gunboat can be destroyed with one rocket.

-bigtruck can be destroyed with three rockets.

 

-buggy and gunboat can be destroyed with 100 bullets (if g_vehicleBulletDamage = 1)

-humvee can be destroyed with 150 bullets (if g_vehicleBulletDamage = 1)

-bigtruck can be destroyed with 500 bullets (if g_vehicleBulletDamage = 1)

 

-vehicle damage code cleaned and made more consistent.

 

 

* If punkbuster is not installed the "punkbuster enable" togglebox will not be disabled

* Fixed a number of serious issues with headshot detection

* Ported a number of sensitive routines into non SDK sources

* Fixed some issues with ladder animations appearing odd to other players

* Added quicksave support for single player (still in process)

* Fixed bug where players name tag didn’t show up

* Fixed bug where console would accept letters as variable states

* Fixed a number of ladder related issues

* Fixed error with warning message in connection dialogue

* Fixed a significant number of bugs relating to quicksave (~100 bugs)

* Fixed a connection dialogue error

* Fixed an incorrectly localized HUD message

* Fixed bug with server shutdown dialogue error

* Addressed a number of issues with the server list UI

* Fixed bug causing cancel button to stop working

* Server create sessions are now saved

* Fixed a bug causing game freezes when player joins and player rotates

* Fixed a rendering issue with Radeon 9600 graphics cards

* Fixed Punkbuster crash when switching from punkbuster online server to hosting LAN server

* Fixed issue with punkbuster icon not showing up in the server listing

* Fixed random crash relating to punkbuster server listing info

* Fixed issue with punkbuster refusing connection to a server that is destroyed and then re-hosted

* Fixed a number of crash problems related to punkbuster server creation with non-dedicated servers

* Fixed issue with punkbuster enabled in multiple server profiles

* Disabled e_vegetation_min_size in multiplayer (used as cheat)

* Added optimizations for character effects including invulnerability shader

* Added optimizations for scoreboard performance. Scoreboard no longer updates fields that have not changed

* Fixed issue where radar would not be drawn correctly with certain game type changes

* Fixed framerate issue when player touched assault ammo pickups

* Fixed issue with password protected servers not removing password after restart

* Fixed issue with spectators not being able to hear ambient sounds

* Fixed message printout for multiplayer statistics (was only working with log_verbosity 1, not it works with 0 (default) as well)

* Fixed listplayer on the client (was only working on the server)

* Changed multiplayer scoreboard system for less bandwidth and easier extendibility

* Fixed bug in scoreboard that reported ping incorrectly by a factor of 2. Pings now appear correctly (half the old values). Note: ping is still the same, the output value was inaccurate)

* Fixed check in server/client version check (now you cannot connect to servers with old network code)

* Fixed bug in submitted Punkbuster ID causing random CD Key hash to be generated. Global ID unique to CD keys is now parsed correctly.

* Added MultiplayerUtils:OnChatMessage a script function which is called on the server for every chat message (to enable saving out chats)

* Made several changes to improve network packet scheduling

* Separated multiplayer and single player weapon code better functionality with mod developers and support for changes to MP balance without affecting single player.

* Made a number of changes to multiplayer weapon parameters, outlined below:

 

All weapons – Increase accuracy while standing still by 25%

Made the medic packs give 50% more health for the engineer class

Reduced rocket launcher clip to 1, no change to lethality.

Increased MP5 damage by 30% with full auto, 50% increase with semi-automatic

Adjusted AG36 damage to head and torso.

Reduced AG36 grenade radius.

Increased OICW accuracy by 30% when zoomed.

Reduced OICW grenade clip to 3 with max carry of 3 in the gun and 3 in reserve

Increased Pancor damage slightly

Reduced P90 damage by 10% and reduced max range by 25%

Increased lethality of mounted weapons.

 

* Improved detection code for player name tags, fixed issue causing name tags not to appear if crosshair was on arms and legs

* Fixed collision detection on the dedicated server with different arm position because of different weapons. Hit detection is now more accurate.

* The record console variable was marked as protected because it opened up some cheat possibilities.

* Fixed a bug that sometimes caused players hit by a buggy not to credit the driver with a kill

* Fixed a number of issues with discrepancies between player cameras in 1st and 3rd person

* Fixed a crash relating to Rcon commands with dedicated server

* Fixed bug with FarCry MOD version number being incorrectly displayed as 1.0

* Reworked a number of installer issues

* Fixed a number of bugs relating to Linux dedicated server porting

* Fixed bug causing mercenary reinforcements to behave incorrectly[/log]

Ursäkta den långa loggen! ;-) Frågan kvarstår dock ifall patch 1.4 verkligen ska vara till för att möjliggöra HDR+AA på Ati X1K, eller om den i stället är tänkt som SM2.0/HDR-patchen..?

 

Och när jag ändå kom in på SM2.0/HDR tyckte jag listan över aktuella spel var väldigt intressant:

[log]Shader Model 2.0 HDR

Act of War: High Treason

Bioshock

Brothers In Arms: Hell's Highway

Brothers in Arms: Earned in Blood

Brothers in Arms: Road to Hill 30

Call of Duty 2

Counter-Strike: Source

(Limited to certain maps)

Crysis

Day of Defeat: Source

Far Cry

(SM 2.0 HDR patch soon)

Gears of War

Half-Life 2: Episode One

Half-Life 2: Lost Coast

Huxley

Red Orchestra: Ostfront 41-45

Stranglehold

Tom Clancy's Splinter Cell: Chaos Theory

(PC version only with patch 1.4 installed)

Tom Clancy's Splinter Cell: Double Agent

(PC version only)

Unreal Tournament 2007

Vanguard: Saga of Heroes [/log]

I H-L 2: E O samt H-L 2: L C funkar det definitivt att aktivera HDR+AA med mina GF 6 & 7! Och ifall det går genom SM-2.0 så varför skulle det inte göra det genom -3.0, om man bara vet hur koden ska skrivas..?

 

[Stålis]

Och ifall det går genom SM-2.0 så varför skulle det inte göra det genom -3.0, om man bara vet hur koden ska skrivas..?

SM 3.0 sägs ju ge bättre HDR-kvalitet eftersom den arbetar med flyttal, och det låter rimligt - men i vilken mån det går att bedöma skillnaderna i praktiken vet jag inte. Högre noggrannhet är såklart alltid att föredra, speciellt om man ska behandla data i flera steg, eftersom varje steg riskerar att minska den, och ständiga avrundningar till heltal försämrar såklart kvaliteten. Jag kan iofs tänkta mig någon sorts sätt där man bygger upp scenen så att man minimerar stegen i behandlingen och därmed bibehåller en högra slutkvalitet som i princip är jämförbar med flyttal, men det borde isf troligen innebära mer jobb, och att spelmotorn är uppbyggd med tanke på det från början. Men det var väl det sättet Valve skrev att de arbetade på?

 

Jag hittade förresten stället där jag just läste det där om att samma del användes för AA och HDR; det var på Bit-tech:

We already know that NVIDIA's GeForce 6 and 7-series were the first GPU's to support FP16 blending and FP16 in the frame buffer, but the nature of the implementation meant that it was not possible to apply Anti-Aliasing while completing an FP16 blend, because the same part of the rasteriser is responsible for doing both functions, and in each case, it has to be the final part of rasterisation.

Då hjälper det nog inte med programmeringen just i det fallet, eftersom det verkar vara just användandet av flyttal som kolliderar med kantutjämingen. Valve använder ju tekniken med heltal i HL2:LC och EO.

 

och dessutom så varför skulle det inte funka med HDR på Ati X1K-kort redan fr o m patch 1.3 förresten? Snart köper jag ett j-a kort bara för jag vill veta! ;-)

Jag är lite inne på samma linje som dig där... :-)

 

/ m

[inlägget ändrat 2006-08-22 12:28:50 av Stålis]

[RN]

SM 3.0 sägs ju ge bättre HDR-kvalitet eftersom den arbetar med flyttal, och det låter rimligt - men i vilken mån det går att bedöma skillnaderna i praktiken vet jag inte.

I brist på nåt eget Ati X1K får man förlita sig till bilder andra har tagit. Och jag hittade också en artikel på bit-tech igår när jag sökte info om det gick att köra SM 2.0/HDR+AA på mitt GF 7 i SC:CT. I spelmenyn går det nämligen bara att välja SM 1.1 eller 3.0 även fast patch 1.5 är installlerad, men jag tänkte att det kanske går att mickla med typ nån cfg-fil..?

 

SM 2.0-implementeringen i spelet verkar dock framtagen exklusivt för Ati-hårdvara:

http://www.bit-tech.net/gaming/2005/08/05/scct_sm20_sm30/1.html

"It turns out that ATI's developer relations team sat down with Ubisoft Montreal and spent a considerable amount of time working together with them to develop a Shader Model 2.0 path for their current generation video cards."

 

Hur som helst tycker iaf jag att bilderna ser ut att ha finare kvalité på 7800GTX med SM 3.0/HDR än X850XT och SM 2.0/HDR. Men tanken på eventuell SM 2.0/HDR+AA är ändå ganska lockande jämfört med enbart SM 3.0/HDR. :-)

 

Jag är lite inne på samma linje som dig där... :-)

Jag skulle faktiskt, om man ska handskas lite vårdslöst med pengar, kunna skaffa ett X1600Pro agp och slänga in det också i datorn! :-) Moderkortet mitt har ju både en agp- och pci-e-port och under ett tag körde jag mitt gamla 9700Pro samtidigt med ett 7900GT i det. Bara på kul och för att det var möjligt och inte för att jag egentligen har nån användning för det (behöver t ex inte två skärmar). Och känslan av att ha både ett Ati- och Nvidia-kort samtidigt i datorn var såklart lite lustig..! ;-)

 

Hm, synd att jag redan har plockat ut 9700Pro-kortet... minns inte ifall det faktiskt kunde köra SM 2.0/HDR+AA (HDR kunde det iaf använda)..? Kanske ska testa igen, men även om det funkar är det ändå i stort sett meningslöst p g a den låga prestandan i kortet. Fast å andra sidan har inte heller X1600Pro nån prestanda som imponerar något vidare...

 

[inlägget ändrat 2006-08-22 17:48:07 av RN]

[Stålis]

Hur som helst tycker iaf jag att bilderna ser ut att ha finare kvalité på 7800GTX med SM 3.0/HDR än X850XT och SM 2.0/HDR.

Det tycker jag också, de har en bättre lyster och ser mer levande ut sas. Men samtidigt vet man ju inte riktigt om det är en helt sann jämförelse principiellt sett mellan de olika metoderna, eftersom spelmotorn väl byggdes upp för SM 3.0 från början, och SM 2.0 lades till efteråt? Det skulle vara intressant med en speltitel som fick en patch åt andra hållet, dvs som hade HDR för SM 2.0 men som fick en patch för SM 3.0. Tänk om det skulle komma till HL2... :-)

 

Hm, synd att jag redan har plockat ut 9700Pro-kortet... minns inte ifall det faktiskt kunde köra SM 2.0/HDR+AA (HDR kunde det iaf använda)..?

Jo, men det ska det kunna, det var därför Valve gjorde en SM 2.0-variant. Också från Bit-techs rapportering om Lost Coast:

The coding team at Valve certainly sweated blood on getting HDR right for Source: in development since 2003, they went through no fewer than four different approaches to the HDR puzzle. Each method had pros & cons, so while one provided the overbright detail needed for blooming, its performance was "so-so" and it broke Multi-Sample Anti-Aliasing (MSAA). As cool as HDR is, Newell was adament that users would not have to sacrifice the ability to run AA in order to gain access to HDR.

 

By the fourth interation, the lads had cracked it: MSAA worked; it worked on all DX9 hardware, with reasonable performance on even a Radeon 9600; indeed the performance was the best of the four methods, with only a small performance hit over Half-Life 2's LDR solution.

Och så kan jag inte låta bli att citera pressmeddelandet för det här nya spelet, eftersom vi talade om fysik och spel tidigare:

Battlefield: Bad Company är ett helt nytt och fristående spel i Battlefield-serien som använder sig av ”Frostbite”, DICE:s helt nya egenutvecklade spelmotor. Spelet innehåller en cinematisk singel-player-del laddad med äventyrskänsla och mörk humor som aldrig tidigare upplevts i Battlefield-serien.

 

“I en spelvärld som är förstörbar till 90% så är möjligheterna oändliga – slagfältet förändras hela tiden och tvingar spelarna att ständigt ändra taktik.” säger Karl Magnus Troedsson, Senior Producer för Battlefield: Bad Company

Skulle man kunna tro att det använder DirectX 10 geometry shader i kombination med fysiksimuleringar? Det var faktiskt något sånt här jag tänkte på, att man kanske kan fälla träd och göra eldöverfall eller översvämma områden för att göra dem svårforcerade etc, som jag antar att det här handlar om. Fast när det kommer till pc är inte klart.

 

 

/ m

 

 

PS Jag har ett X1900GT på väg i posten.

[inlägget ändrat 2006-08-23 19:01:49 av Stålis]

[RN]

PS Jag har ett X1900GT på väg i posten.

Aha! :-) Skulle i så fall såklart vara intressant med lite upplysningar om Far Cry HDR+AA. Hade också varit kul att få höra lite om SC:CT, Oblivion m fl..!

 

Du har väl förresten många spel på kö nu att köra igenom; F.E.A.R, bara för att nämna ett lysande spel, m fl..? :-) Är väl förresten på gång en expansion också som bör dyka upp ganska snart.

 

[Stålis]

Jo, precis! Måste ju bara vänta tills alla delar är levererade, iom att det blir en övergång till pcie, men kommer såklart att avlägga rapport när "budgetuppgraderingen" är genomförd. :-)

 

Det är lite synd vad det gäller Oblivion att AA/HDR-fixen endast finns till Catalyst 6.6, speciellt med tanke på att OpenGL-spel som Quake och Prey fick en fin liten hälsosam boost nu med Catalyst 6.8 (måste ju ta tag i Prey också någon gång...). Men det sägs att arbete pågår med att inkorporera den som en del i WHQL-godkända drivrutiner istället för att lägga ner tid på att göra en separat fix varje gång. Det beräknas vara kalrt senast i oktober, dvs till 6.10.

 

/ m

 

[RN]

...men kommer såklart att avlägga rapport när "budgetuppgraderingen" är genomförd. :-)

Den rapporten ser jag fram emot att läsa! För att få reda på saker och ting räcker det ju nämligen inte med att bara läsa olika testsidor/forum, utan man måste hålla på och bängla och mickla på egen hand också, eftersom olika sidor kan påstå helt olika saker. Och för endel specifika frågor verkar ingen veta ett dyft nånstans öht! Förutom då att man brukar stöta på en massa smarta förståsigpå:are och bezzervissers överallt – som givetvis har svar på allt vad det än är frågan om – att försöka sålla ut från mängden..! ;-)

 

Min uppfattning om dig är dock att du ställer dig ödmjukt frågande inför saker du inte har ordentlig koll på, söker t ex info och testar själv, och ger inte heller andra några råd förrän du har ordentligt på fötterna i nån viss fråga.

 

Frågan om GF 6 & 7 och HDR+AA ställer jag mig iaf så här till nu:

 

Genom SM 2.0 så definitivt ett: ja, det funkar!

 

Genom SM 3.0 så fortfarande inget definitivt nej, utan snarare nja..! ;-) Verkar ju faktiskt funka i vissa sammanhang men inte i andra. Än har jag inte kastat in handduken men har inte haft tid och lust att tjorva mer de senaste dagarna, men ska nog säkert ta tag i det och utföra fler tester så småningom.