Vyznam dual core

[Petrik]

1)nevim, proc by se zrovna meli zastavit, klidne se muzou srazit, porazit, odrazit...ale to je detail.
2)Takze podle tebe, jestli to chapu spravne, bude tvuj algoritmus davat odlisne vysledky, podle toho, jakeho panaka zacnes resit drive a jakeho pozdeji, prestoze se oba pohybuji zaroven, tedy jakoby paralelne (mysleno casove)? Mozna to je jen nedorozumeni, protoze jsi dal priklad se sachama, coz je tahova zalezitost (nepohybuji se soucasne), ale tohle mi pripada jako klasicka chyba, ktera vznika tim, ze se nativne paralelni problem (pohyb dvou nezavislych panaku) resi seriove. Spravne by to prece melo byt tak, ze jesltize se oba panaci pohybuji soucasne proti sobe (tak jsem to pochopil a myslel od zacatku), tak by zadny nemel dostat prednost (jako prvni panak v tvojim reseni), ale oba by na tom meli byt stejne, ne? To znamena zadny by nemel mit vyhodu, ze popojde na volne misto pred nim a druhy ostrouha... Pri paralelnim pocitani v tom neni zadny problem (nebo ho nevidim), u serioveho se to musi nejak dodatecne resit a opravovat... proste skutecne mi nepripada stastne resit paralelni zalezitosti seriove...

No, tak pokud jde o panáky, tak co se stane ve hrách, když jdou dva proti sobě? Zastaví se, jak jinak. To se stane ale i v tom případě, co jsem napsal. Je to jako bys hrál šachy nebo jinou tahovku. První tam má místo, tak se tam hne. Druhý tam už místo nemá, tak zůstane stát na místě. Takhle to prostě zůstane a až když se řeší další cyklus fyziky, tak první panák už bude stát na místě, protože před ním už místo není a druhý panák to samé. <-- tohle je případ, kdy mezi panákama v prvním okamžiku bylo ještě trochu místa. Pokud by tam bylo míň místa než kolik je delta x toho panáka, tak už by to vyhodnotil, jako, že tam místo není už v tom prvním kroku. Pokud tam však místo je, tak neni důvod tam toho panáka nepošoupnout jenom proto, že tam možná bude chtít i panák dva. Kolize je zároveň ošetřená tím, že první panák si samozřejmě kontroluje jestli je předním něco jiného, takže se nemůže cíleně zaseknout do druhýho panáka. Stejně tak druhý panák už řeší tu fázi, kdy je první panák zpracován a pokud ten se k němu pošoupnul, tak už prostě před sebou žádný místo nemá a tak se nehne. Takže vlastně k žádnýmu zaseknutí do sebe nedojde. Akorát se na sebe nalepěj jak dva buzíci. Nic víc. Takhle jak jsem to popsal se to doopravdy řeší ve hrách a takhle to i funguje. Vim to, protože jsme to takhle už i implementovali. Jestli to potěší, tak ti ten zdroják klidně i pošlu (pure C a OpenGL).

Mozna ze se to tak skutecne dela, nevim, ale to se pak muze lehce stat, ze objekty, ktere by se za vysokeho poctu FPS srazili, se pri malem FPS jednoduse minou, protoze ta jejich kolizni poloha se netrefi do zadneho framu...jestli mi rozumis. To by pak tedy chovani fyziky bylo silne ovlivnebo poctem FPS, coz se realne nedeje, alespon v dobrych hrach s havokem rozhodne ne. Takze podle me se pletes a trajektorie se proste pocitat musi. Jinak bys nemohl spolehlive detekovat kolizi, nebo me alespon zadny rozumny zpusob bez trajektorie nenapada. A jakmile se pocita trajektorie, neni problem s paralelnim pocitanim fyziky...

Samozřejmě že počítáč jen výslednou polohu, protože trajektorie je přece blbost. Situace se nezobrazuje v nějakém spojitém rytmu, ale po snímcích. Že je to plynulé, splyne člověku v hlavě. V reálu je to ale snímek po snímku, stejně jako třeba fotky. Ty potřebuješ vědět, jaká bude poloha panáka v následujícím snímku, ne jaká bude za deset snímků dopředu (to tě nezajímá, protože do té doby do něj může hráč střelit kulometem, a tak změnit jeho rychlost pohybu atp.).

[Warran]

Sice to s významem dual core nesouvisí, ale když se tady řeší ty paňácové, tak si přisadím.

Dobře mám dva panáky:
-pohyb panáka 1 (panák P jak ho značí Eagle) počítá thread 1 na jádru 1.
-pohyb panáka 2 (panák R jak ho značí Eagle) počítá thread 2 na jádru 2.

Oba se chtějí posunout na to samé místo. Pří sériovém výpočtu v jednom threadu se ta situace ošetří, jak už tady Eagle a Swarm popsali. Zastánci dual core chtějí danou pozici (tedy fyzické místo v herní scéně) zamknout. Můžou tedy nastat tři situace:

-při výpočtu threadu 1 se na výpočet panáka 1 dostane dřív než se ve výpočtu threadu 2 dostane na výpočet panáka 2. Panák 1 si to místo zamkne a posune se tam. Panák 2 zůstane stát.

-pří výpočtu threadu 2 se na výpočet panáka 2 dostane dřív než se ve výpočtu threadu 1 dostane na výpočet panáka 1. Panák 2 si to zamkne a posune se tam. Panák 1 zůstane stát.

-při výpočtu threadu 1 se na výpočet panáka 1 dostane ve stejném okamžiku jako se ve výpočtu threadu 2 dostane na výpočet panáka 2. Oba to místo zamknou Nebo co jiného udělají


Situace nastíněná ve třetí odrážce je celkem málo pravděpodobná, ale ošetřena být musí. Jak?
Leda snad ve více threadech spočítat místa kam by se panáci chtěli posunout a nebrat ohled na možné kolize. Potom v jednom threadu ta místa projít a zjistit, zda se někteří panáci nechtějí dostat na to samé místo. V pripade ze ano rozhodnout který z nich se tam dostane a který zůstane na místě.

[Eagle]

Mozna ze se to tak skutecne dela, nevim, ale to se pak muze lehce stat, ze objekty, ktere by se za vysokeho poctu FPS srazili, se pri malem FPS jednoduse minou, protoze ta jejich kolizni poloha se netrefi do zadneho framu...jestli mi rozumis. To by pak tedy chovani fyziky bylo silne ovlivnebo poctem FPS

Máš pravdu, že pokud by počet fps klesnul pod určitou hranici, mohlo by to dělat značné potíže. V tom případě by to šlo vyřešit tak, že bys fyziku počítal s omezením na nějakou uraženou vzdálenost třeba víckrát pro jeden objekt v jednom průchodu. Pokud by ta vzdálenost nebyla tak veliká, nedělalo by to problém. Výpočet by se tím příliš nezesložitil, protože to, jestli spočítáš 500 metrů uražené vzdálenosti vcelku nebo po 20 metrech, je poměrně lhostejné (nejvíc času zabere interakce s okolím a té je v 500m 25* tolik co v 20m)

Počítat trajektorii mi nepřijde příliš reálné, neboť to by byl výpočet extrémně složitý a navíc by prakticky nešel paralelizovat. A trajektorii bys v dalším kroku stejně nejspíš musel zahodit. Představ si, že máš čtverec, který protneš různými přímkami (trajektorie pohybu). Jakmile by se dvě přímky protnuly, měl bys potenciální kolizi a musel to řešit (což by zjevně muselo být sériově, abys zabránil nechtěným efektům).

[Semik]

Ja kupujem vedsinou to najlacnejsie, ale tak aby som z toho mal najviac. (OC)
DualCore bude premna zaujimavy ked nebude CPU ktore po natakteni ziska podobny vykon. Teraz to vidim len ako snahu CPU fieriem presadit novy trend predajnosti kedze MHZ stagnuju. Horsia alternativa bude ked uz trh neda inu moznost a nanuti predrazene Dual-CPU.

Momentalne by mne Dualcore ponukal maximalne rychlejsi Task, ale to mozem investovat aj do pametoveho systemu a vysledok bude podobny. Ked bude Dual za cenu single idem do toho ale hned

[Petrik]

Uz tohoto tematu asi nechame, nebot jak Saman spravne poznamenal, ani jeden tomu nerozumime...me uplne staci, ze on prohlasil (a nejenom on), ze pokrocile fyzikalni enginy jdou bez vetsich problemu paralelizovat, cehoz je napr. source engine dobrym dukazem. Koukni treba na particle simulation, tam mas hromadu uvlivnujicich se (predpokladam) kulicek a narust vykonu je az do 4 jader 100% linearni

Máš pravdu, že pokud by počet fps klesnul pod určitou hranici, mohlo by to dělat značné potíže. V tom případě by to šlo vyřešit tak, že bys fyziku počítal s omezením na nějakou uraženou vzdálenost třeba víckrát pro jeden objekt v jednom průchodu. Pokud by ta vzdálenost nebyla tak veliká, nedělalo by to problém. Výpočet by se tím příliš nezesložitil, protože to, jestli spočítáš 500 metrů uražené vzdálenosti vcelku nebo po 20 metrech, je poměrně lhostejné (nejvíc času zabere interakce s okolím a té je v 500m 25* tolik co v 20m)

Počítat trajektorii mi nepřijde příliš reálné, neboť to by byl výpočet extrémně složitý a navíc by prakticky nešel paralelizovat. A trajektorii bys v dalším kroku stejně nejspíš musel zahodit. Představ si, že máš čtverec, který protneš různými přímkami (trajektorie pohybu). Jakmile by se dvě přímky protnuly, měl bys potenciální kolizi a musel to řešit (což by zjevně muselo být sériově, abys zabránil nechtěným efektům).