mondjuk van egy beállításod 50fps-re. de a géped sokkal többet is elő tudna állítani (ez lenne a cél ebben a játékban). ekkor azt látod, hogy 50 fps, hozzá mondjuk 13.75ms. A MainThread-ben kevesebbet, a többiben még kevesebbet. Ha azt írná ki amit írtál, akkor nem tudnánk, hogy mi a helyzet. minek kiírni akkor az 50fps alá, hogy 20ms. azt a hülye is tudja. nincs értelme. viszont ha az elkészülési időt írom ki, akkor rögtön tudom milyen irányban kell elmozdulnom. Amennyiben ha a játék teljesen "kicsinálja" a gépet, akkor valóban azt fogod látni amit írtál. Az 50fps-hez 20ms lesz kiírva. Na mi ebből tudjuk, hogy ott gond van, és ilyenkor az a cél, hogy azt a 20ms-ot csökkentsük. Mostanában divat, hogy úgy gyorsítunk meg egy programot, hogy a kódban figyeljük ezeket az értékeket, és átállítunk paramétereket. Pl. a felbontást. Ott is azt kell figyelni, hogy a kép elkészülési ideje mikor éri el a maximumot (50fps-nél a 20ms). Tehát amit Sanya bácsi linkelt képeken, ott pont az látszik, hogy dolog van. Gondolom ezért is piros. Ha a 31fps alatt pl. 10ms lenne, valszeg enyhébb színű lenne. Talán így már érthetőbb a különbség.
Ezek a technológiai dolgok nem olyan egyszerűek. Ez a szimulátor meg akár a többi is, nagyon erőforrásigényes. A minél több mag használata egyáltalán nem jelenti azt, hogy gyorsulnának a dolgok. Ha veszek egy egyszálas alkalmazást (csak a MainThread), annak adhatsz több magot nem fog gyorsulni (ez az egyik véglet). Viszont ha annak a magnak a frekvenciáját tudod növelni, meg a hozzá tartozó memóriáét is, akkor érsz el gyorsulást. Többszálas alkalmazásoknál sem tudunk mindent külön szálakra tenni, és amúgy is az összes szálnak szinkronizálnia kell a MainThread-re (egyébként a process thread-je), mert az összes be és kimenet csakis ezen a szálon működik. Úgyhogy egy alkalmazás sebességét a MainThread működése határozza meg. Az meg jelenleg még ebben a gyönyörűen optimalizált valamiben is elég combos frekvenciát igényel. Amúgy az ideális CPU úgy nézne ki, hogy kellene egyetlen fizikai mag ami mondjuk 10GHz-es (nem kell hozzá HTT), de ne a 0-ás mag legyen. A többi mag nem érdekes, amik most vannak teljesen jók. Viszont egy ilyen gyors maghoz, gyors memória is kell. A mostani RAM-oknak sajnos eléggé lassúak (DDR4), vagy nagyon nagy a működési ciklusuk (DDR5). És akkor lehetne gyorsulást elérni azzal, hogy a MainThread-et arra a magra kényszeríteni. A windows kernelben pedig azon a magon letiltani a Cooperative és a Round Robin üzemmódot. Úgy mindig aktív lehetne, bár ez nagyon ellene van a kernel ökölszabályainak. Mikrokontrollerekben viszont sikeresen használják. Szóval nem csak az elmúlt 5 évben nem történt ezen a fronton nagy változás, de ez lesz 10 év múlva is. Legalábbis a windows-ban.
Teljesen mindegy, hogy Vulkant vagy OpenGL-t használsz. Nem ezek a kezelők használják ki a gépben rejlő bármit, hanem maguk a programozók. A Vulkan az OpenGL-hez képest még ráadásul rohadt nehéz téma, iszonyat sok buktatóval. A mai napig nem tanulták meg jól a használatát (köztük én sem). Viszont az OpenGL-el is meg lehet csinálni azt amit a Vulkannal, csak másképp (és könnyebben). Maga a Vulkan is inkább csak az AMD tulajoknak kínált némi pluszt. Azt viszont meg is kapták (ahol jól le lett programozva). Az nVidiasok meg jól elvannak az OpenGL-el. Magát az OpenGL-t is már rég újra kellene írni (elég öreg már szegény), de elég nehéz lenne bevezetni, elfogadtatni. Max. akkor ha valami óriási durranást sikerülne benne kitalálni. Arra meg elég kicsi az esély.
De egyébként összességében elég sokat fejlődtek a dolgok pl. az elmúlt 10 évben. Vegyél elő egy FSX-et, vagy P3D-t, sokkal jobban futnak mint 10 éve. Nálam az FSX hasít mint állat. 10 évvel ezelőtt nem így volt. Az XPL11 is csodás a mostani gépemen, az előzőn csak megfelelően működött.