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.).