Sarkallatos pont, hogy mi legyen a megcélzott minimum gépigény, amin a megírt szoftvert még épp át akarjuk paszírozni relatíve használhatóra.
Különösen nehéz a döntés akkor, ha mondjuk grafikát is használ a szoftver, ezért valamilyen 3D API-t is támogatni kell, ugyanis jelenleg az emberek kb 10 generációnyi grafikus chipet használnak párhuzamosan a piacon, rengeteg gyártótól, főleg, ha mondjuk az ARM/Android világával is számolunk. Persze ha szoftveres renderert használunk, akkor ilyen gond nincs.
2000 tájékán emlékszem, hogy volt egy fióknyi grafikus kártyám, amiket mind teszteléshez használtam. A DX7-et használó megoldásom akkoriban nvidia, ati, 3dfx, 3dlabs, matrox, sis, s3 kártyákon is remekül kellett, hogy menjen, vagy legalábbis el kellett, hogy induljon, és valamilyen szinten folyamatosnak is kellett lennie. Persze ez akkor még természetesnek számított: akkor 3-4 éve jött be egyáltalán a 3D gyorsítás a köztudatba, és az összes addig kitermelt kártyákat tesztelni kellett, hisz relatíve újak voltak.
Aztán ahogy telt-múlt az idő, teljesen új eljárások, és grafikus API-k jöttek. Megjött a DirectX8, aztán a 9 (ami szerencsére visszafelé kompatibilis még a dx5-ös kártyákkal is), no és persze az OpenGL is évről évre egyre inkább hízott újfajta vertex pipelinekkel, rendering módokkal, később ilyen-oylan shaderekkel.
És a legnagyobb az az még ma is, hogy mindig, amikor megjelenik egy új technológia, kb 2-3 év múlva már el is avul, elfelejtődik, sőt, akár a driverekből is kiszedik, vagy eleve el sem terjed, ezért aztán a programozók nagyrésze még mindig ott tart, hogy glVertex3f, esetleg, ha androidon is, OpenGL ES-en is futtatni akarja, akkor glVertexArray. Tehát sikerült konzerválni a grafikai megjelenítést a programok kb 99,9%-ban az 1994-es szinten, ugyanis kizárólag ez az, ami a platformok, konfigurációk széles tárházán is probléma nélkül képes futni. A baj akkor jön, ha a megírni kívánt szoftver, játék, stb, az komolyabb képességeket igényel, pl árnyékok, vagy nagy polygonszám. Itt aztán borul a képlet, kivéve persze, ha valaki szoftveres renderert írt, hogy ezt az egész agyhalált megspórolja.
Mi a helyzet a grafikus chipekek oldalán?
Sajnos a helyzet nem túl jó, a gépek frissítési ciklusa 2000 után eléggé lelassult, és elült. Aki mondjuk 2000 tájékán vásárolt egy akkoriban még középkategóriás laptopot, az jó eséllyel még ma is azt használja. Egész egyszerűen az, akinek mondjuk van egy 1 Ghz-s VIA masinája OpenGL 1.1-es Savage grafikus chippel, az nem szorult rá arra, hogy ezt a gépet kicserélje, vagy ha igen, akkor lepasszolta lemenő/felmenő családtagjainak, akik ezt használják. Így aztán nem szabadulhat meg a programozó attól, hogy a legprimitívebb grafikus kártyákat is támogassa. És arról se feledkezzünk meg, hogy még tavaly is árult az Intel olyan Atomokat, amikben a GMA950-es chip OpenGL 1.4-es leszármazottai ülnek. Így aztán biztosak lehetünk abban, hogy az OpenGL 1.x pipelinet még mindig támogatni kell, és ezen semmi sem változtat. Aki 2006 tájékán arra számított, hogy elegendő megírni a grafikus enginet mondjuk ARB shaderekkel, mert úgyis pillanatok alatt elavulnak a régi grafikus chipek, az hatalmasat hibázott. És ha megfigyeljük, akkor ezek a technológiák, emberek, megoldások, stb alapvetően ki is hullottak a piacról, más iparágakba mentek dolgozni, és ma már nem is igazán emlékszünk rájuk, vagy a megoldásaikra. Akik viszont a legprimitívebb engineket írták, azok vígan portolták Androidra, OpenGL ES 1.x alá. Tehát egyszerűen, ha hardveres renderelést akar valaki, akkor nincs az a low-end, 20 éve elavult chip, fiók mélyéről előkapart S3, amire ne kellene kijavítani az engine hibáit, hiába írunk 2015-öt.
Notice me, sempai!
Androidon persze ugyanaz a helyzet, mint a PC-n, ahol mindenféle gyártó érdekes, és bugos kreálmányát kerülgethetjük OpenGL ES 1.x-től kezdve mindenféle (nem működő) megoldásokon és technológiákon át.
Mi a helyzet a processzorok tekintetében?
A processzorok területén némileg egyszerűsödött a terep. Legyen szó PC-ről, telefonról, vagy tabletről, a 800 mhz alatti eszközök aktív használatban kimutatható mértékben már nincsenek jelen a piacon. És mint derült égből a villámcsapás, 800 mhz-en megindul az élet, és a nyüzsgés, és hirtelen felbukkannak a klasszikus AthlonXP-ken át az újabb Atomokon, 10 ezer forintos Vortex86-os, VIA-s netbookon keresztül, beleértve az ARM gyártók széles tárházát is, és mindenféle egzotikusabbnál egzotikusabb gyártót x86-on is. Ma a 800 mhz a választóvonal szerintem. Annál gyengébb processzort támogatni szinte biztos, hogy semmilyen körülmények között nem kell majd, legyen szó akármilyen elvadult afrikai nyomortelepről is, a 800 mhz-et jelentő bűvös szám ott is jelen lesz. Felesleges időt, és erőt pocsékolni az ennél is régebbi, múzeumba való, elavult termékekre, viszont a 800 mhz-s processzorokra valahogy össze kell kalapálni a terméket, ha törik, ha szakad, ugyanis ezek tömegével jelen vannak még a PC piacon is. Itt nincs olyan nagy probléma, elvégre, amit az ember beleír a fordítóba, az fordul le, fordítsa akár 32, akár 64 bites architektúrára, viszont figyelni kell arra, hogy fordításnál a march=i486 kapcsolót adja meg x86-on, hogy biztosan fusson az újabb utasításkészleteket nem támogató 32 bites processzorokon is. 64 bit esetén pedig értelemszerűen a march=k8 kapcsolót kell megadni, ami az összes 64-bites x86 esetében lehetővé teszi a kód futtatását.
Persze a 800 mhz nem egy diszkrét szám, ha valaki egy 600 Mhz-s AMD Duront talál, akkor se lepődjön meg. Egy processzor sebességét számos más tényező is meghatározza, ami befolyásolja, hogy mennyire használható ma.
Az olló szélessége a low-end, és a high-end között
Manapság eléggé kiszélesedett az olló az alsókategória, és a felsőkategória között. Korábban nem volt még olyan szituáció, hogy két évtizednyi technológia egyszerre a piacon legyen valamilyen inkarnációban, és ezeket mind egyszerre támogatni kelljen. Ha valaki 2000-ben (Socket7 korszak) egy programot megírt, annak nem kellett futnia 15 évvel korábbi Videoton TV computeren, vagy Commodore128-on, hanem egész egyszerűen elegendő volt a Pentiumokon, és az ezzel ekvivalens AMD-ken, Cyrixeken, Rise és IDT processzorokon garantálni a szoftverek futtatását, egészen a Windowst még kényelmes sebességen futtatni képes, erősebb 486 processzorokig bezárólag. Ez a legroszabb esetben is 10, de a gyakorlatban inkább 6-7 évnyi processzor támogatását jelentette, ahol a csúcs, és a leglasabb megoldás között a sebességkülönbség alig-alig volt tízszeres sebességkülönbség. Ma már a legújabb generációs processzorok között is majdnem százszoros a különbség (pl 8 magos desktop i7, vs 1 magos HT-s atom), nem beszélve arról a rengeteg 15 éves gépről, ami a Socket7 korszak után a nyakunkon maradt, a már említett bűvös 800 mhz-től kezdve. Valószínűleg ezek a gépek még nagyon sokáig velünk maradnak.
