"zerintem az optimalizáció nem a fejlesztõ dolga ([...]), hanem a fordítóprogramé."
Ez csak részben igaz. A fordító tudja optimalizálni a kódot alacsony szinten, de nincs befolyása a magasabb szintekre. Pl. Nem tud mit kezdeni azzal, hogy egy sztring paramétert konstans referencia helyett érték szerint adsz át. De ami még fontosabb, nem tudja helyetted optimalizálni az algoritmusaidat. Nem tud egy beszúró rendezést qsort-ra, vagy a tömbödet hashmap-re cserélni. Ezen kívül ahhoz, hogy a fordító jól tudjon optimalizálni, egy csomó fontos szabályt be kell tartani. És további trükkökkel lehet még segíteni neki. Figyelni kell pl. olyan dolgokra, hogy a CPU cache-be beférjen az adat, ha lehet, mert akkor sokszor gyorsabb a feldolgozás. Ahhoz, hogy ezeket az ember mind tudja, és képes legyen megfelelõen alkalmazni, rengeteg tanulás, és még több gyakorlás kell.
Nem arról van szó. Csak felhoztad, mint hatalmas gépigényre magyarázatot a kiválló AI-t. Kiválló AI nyomokban sem található meg a játékban, ez lett volna a mondanivalóm lényege.
És a farcry-ban meg a többi iqlight fps-ben mi van? Nem külömbek azok sem full script az egész. Mindegyikben ugyanaz: grafika, és más semmi... ezért untam meg pár éve a sima fpseket.
Érdekes, optimizáltabb kódot lehet írni, most a jelenlegi fejlesztõkörnyezetekben pl. .NET, Java is, de egy OS hardware-igénye nem ettõl függ, mert az OS alapjában nem .NET-ben vagy Java-ban van megírva. Viszont a baj ott van, hogy ma nagyon kevés a programozó, ma mindenki hipergyors tanfolyamok, 3-4 éves egyetemen vagy 1-2 Mastering XYZ in 21 days féle karierr-szerzõktõl származó könyvbõl tanult. Azok a programozók akik igazán tudják, értik a dolgokat akik nem csak dumában tudnak kódolni azok kevesen vannak és komolyan kétlem, hogy egy 100 dollcsis gép kifejlesztésénél megfizethetõek lennének. Tehát itt olcsóért akarunk minõséget, ez tiszta utópia, akkor amikor még drágáért sem tudunk minõséget elõállítani, mert van egy nagy project, kellenek hozzá fejlesztõk, a papíron ugyan mindegyik 999 dologhoz szakember, de amikor elkezdesz dolgozni velük akkor veszed észre, hogy valójában édes kevés dologhoz értenek átfogóan, hogy nem tudják mi a lista vagy a binary tree, hogy nem értik az objekt orientált fejlesztés alapjait, hogy amikor egy SQL queryt szerksztenek akkor annak futtatása 77x több idõt vesz igénybe mint ha optimizálva lenne, hogy sokszor magát az adatbázisokat sem képessek normalizálni, hogy a szemantikát a programlogikával akarják megoldani, pedig az az adatbáziskezelõ dolga, és ezek még mind a gyengébb területek. Egy rendszerptogramozónak sokkal nehezebb a dolga, sokkal több tudást kell hozzá, de te ott állsz és nézel, mert sajnos ez a legjobb ami van, jobb nincs, de már így is drága, mert igaz, hogy 3x olcsobban dolgoznak mint a felsõ kategória, de 5x kevesebb a produktivitás, 12x több hibát csinálnak 3x igényesebb lesz a software a hardware-vel tekintetben stb. Szóval ez a valóság és ettõl nem lehet megszökni, fõleg nem rövidtávon. Optimizáltabb kódot kérni kevesebb pénzért a meglévõ IT oktatáson alapuló "shoot, aim, ready" környezetben egyenessen határos az értelmetlenségel. Szóval a felsõbbszíntû nyelvek és fejlesztõi környezetek nem hibássak a gyengébb programozásért, hanem éppen fordítva részben a gyenge programozók miatt jöttek létre megpróbálva megoldani a fejlesztõk és itt hangsúlyoznám sokszor a jó fejlesztõk hiányát. Jó fejlesztõ .NET-ben és Java-ban is optimizált kódot ír, persze az közel sem olyan optimizált mint amilyen lehet C-ben vagy assembly-ben, de a hardware ezt kompenzálja általában. Más kérdés, hogy valaki lehetetlenséget akar csinálni 100 dollárért, akkor ugye minndennel baj van, és hol lehet elméletileg lefaragni a legtöbbet a software-bõl, pedig fenét, éppen ott lehet a legkevesebbet, a software nélkül a hardware nem ér semmit, a szoftware funkciónalitása pedig fordítottan arányos az optimizációval ha a meglévõ erõforrásokat figyelembe vesszük. Tehát nem ártana egy picit megkérdezni a valós IT világ résztvevõit, hogy az ami egy egyetemi katedráról esetleg logikus és igaz, a valóságban sokszor sajnos nem igen állhat stabil talajra.
Kérdésedre a válasz: script. Akkor lenne AI-ra emlékeztetõ valami, ha teszem azt a szokott útvonala elé tennél egy ládát és nem megkerülné hanem rácsodálkozna, vagy ha harcos akkor esetleg mérgében szétverné, ha varázsló akkor elteleportálná az útból... de ez a megkerülés egy egyszerû útkeresõ algoritmus /A-ból B-be a legrövidebb úton/.
Ettõl függetlenül harc közben korrektül viselkedik az AI, meg bizonyos dolgokra is egész jól reagálnak de ez sincs túlbonyolítva. Jó példa az "ostoba" AI-ra, ha felmászol 1 ház tetejére és elkezded onnan lõni az enemyt... fut jobbra-balra, néha megáll, néha beleolvad a tereptárgyba, falakba -így tovább nem tudod lõni, esetleg vissza kiverekszi magát stb.
Csak azért reagáltam le egyáltalán az elején, mert nekiálltál fényezni, hogy mennyire ai, és mennyire nem említhetõ egy lapon a far cry-al, hisz az csak szép. Namost a far cry tereptárgyakat kihasználni próbáló, harc közben valamellyest taktikázó ai-ját én némileg többre tartom ennél, ahol a mob harc közben összevissza rohangál, és a legegyszerûbb trükkökkel is kijátszható.(pl. távolról sebzõ egység, ha álsz egy fal vagy bármi takarás mellett, és ki-be szaladgálva osztod rá az áldást, eszébe nem jutna hogy közelebb jöjjön)
Az amit te az oblivionban ai-ként véltél felismerni, leginkább 90%ban scriptelt esemény. Ami igen gyakran képes erõs bughalomba fulladni, tolvajként ez nálam gyakori quickload-ot eredményezett sajnos, így nem tudok felette nem es egyszerûséggel szemet hunyni.
Ettõl még jó játék, de csak azért mert szépen csillog, és képes valami pozitívat felmutatni a mostani gyenge felhozatalban belátható, hogy rengeteg hibát tartalmaz.
Ebben van igazság. Viszont a linux kernel önmagában nem tétel ebbõl a szempontból. Ugyanis muszáj vagy ráküldeni egy shell-t, egy grafikus szervert, és egy ablakkezelõt. A felhasználói programok, vagy az ablakkezelõ appletjeit ne is említsük. Szóval egy korszerûen felszerelt, és eladható OS-nél a kernel optimalizálás nem egy akkor tényezõ, mint hiszik. Ha így jobban tetszik, amit megnyersz a rév-en, elvesztheted a vámon. A linux nem hízott el, egyetértek. És optimalizálással, meg jó szoft kibválasztásával félelmetesen fel lehet gyorsítani az OS-t. (suse 10.0 47 sec alatt butul nálam) De oda kellett figyelni mit töltök be, és mit nem, és az ablakkkezelõ sem KDE. (enlightenment)
Pár sorral ez alatt olvastam hogy a linux is elhízott ==> Na szóval ez így marhaság!!!!
Ha optimalizálod a kernelt és nem töltesz be fölös modulokat akkor máris villám gyors + nem kell 16 asztalt használni meg full 3d-s ablakkezelõt!!!! jah superkaramba meg a haverjai........
MÉG MINDÍG A LINUX A LEGJOBB
Szerintem programozástechnikai szempontból nagyon kézenfekvõ az Oblit a FarCry-hoz hasonlítani. Lényegében az AI szintje sem igazán eltérõ a két programban (a FarCry nem is olyan hülye, az Obli nem is olyan okos).
Én az Obli lassúságát abban keresném, hogy a fejlesztõk, hogy legyen idõ a tartalmak kifejlesztésére, megvették a SpeedTree-t meg a Havok-ot és azokat belerakták a progiba. Ezzel két évet megspóroltak. A FarCry-nál a Crytek mindent maga írt, viszont így az a két évet is a motor reszelésére fordították. A játékidõ tehát egy lapon sem említhetõ a két játéknál, viszont a FarCry-ból is simán lehetne RPG-t csinálni, még gyors is lenne: csak ugye +2 év.
Azért a Delphit és a Visual C-t nagyon erõs egy lapon emlegetni a VB-vel. Sõt, még a C-t a Delphivel együtt is. Esetleg C++.
Másrészt ne haragudj, de nem tudom elfelejteni hogy pár hete valaki azt mondta hogy egy byte-on 64 szám ábrázolható. Nem emlékszel ki volt az? :)
Erre meg hogy "készülnek azok a proginyelvek ahol már nem kell programozni tudni" azt tudom mondani, hogy ezek a nyelvek már rég elkészültek. Egy hétköznapi progihoz már most is csak dobálgatni kell a kontrollokat és összehúzni pár property-t. Az algoritmusok programozását pedig így is-úgy is kézzel fogod leprogramozni, senki nem csinálja meg helyetted.
Azért 19 mega egy kicsit túlzás, nem? A hullák eltünnek, az ellenfelek scripteltek, mit kell ennyit menteni? A meglévõ fegyverek, meg a pozíciód 3d-ben 10k? A többi?
Nem láttam semmit ,nem is kell. Egy fps mentés nem lehet bonyolultabb mint egy full játék.
Ott se sokáig, pl. az x360-as gamékból megjelenéskor gyakorlatilag nem volt olyan ami bugon kívül mást is tartalmazott volna. Amióta beszállt az MS, és nem lehet évekig lazsálni a kódolással, ott is szorít a határidõ.
Az XP-nek is volt hw igénye, aztán rakás cikk van arról hogy milyen szutykokra felnyomták egyesek. Lehet hogy lehetne valamivel kisebb is, jó is lenne ha szarrá optimalizálnák, de amíg egyfolytában késnek vele, meg sorra hagyják ki az újdonságokat hogy egyáltalán belátható idõn belül meg tudjanak jelenni vele, addig van ott fontosabb dolog is. Na ha ezt még ráadásul asm-ben kódolnák, talán 3010-ben el is készülne.
Ja, ha már asm, adok hozzá linket is :). Assembly, érdemes nézegetni a 64k-s részeket, a 2005 results szekcióban.
Az ai lenne? Hogy fix szövegkönyvbél bevállogat a játék véletlenszerûen párat? És ez adott esetben ahhoz vezet, hogy a barlanban a vámpírok arról beszélgetnek, hogy a vámpírok milyen undorító lények? :D
Oké, bocsánat. Belátom tévedtem. Ez tényleg fergeteges ai, hatalmas gépigénnyel :)
Hmm, szerintem egy valamit felejtetek el, teljesen más 2-5 emberrel valami kis saját projekten dolgozni, mint amikor 50-100 ember több éven keresztül reszelget valami rendszert folyamatosan. Ráadásul ez az embertömeg idõközben cserélõdik is. Nagyon jól nyomon lehet követni a progik életciklusában, hogy elindulnak valami kis páremberes projektként, akkor még teljesen optimalizáltak, gyorsak, tök jók. (Gugli, icq, kazaa, vagy épp az office is így kezdõdött, most is vannak ilyen kezdeményezések, ezek a legszebbek.) Aztán ha több ügyfélnek el van adva, egyre több fejlesztõ kell, folyamatos fixek, párhuzamosan futó verziók, stb-stb egyre több és több ember dolgozik rajta, már muszáj menedzselni az egészet. Na ilyenkor az optimalizáció már erõsen a háttérbe szorul, a határidõk és (jó esetben) az integrációs tesztek veszik át a fõ szerepet. Kódszinten teljesen máshogy fog kinézni egy asm versenyre készült páremberes csutkáig kioptimalizált és tömörített demo (volt 64k-ban full opengl-es játék is hangokkal mindennel együtt) mint többtucat "szalagozó" által heggesztett majd reszelgetett "gyártott" kód. Ha még alulmotiváltak is (ld. költségracionalizáció) akkor el lehet képzelni a keletkezõ minõséget. Márpedig szerintem az senkit nem fog meglepni, hogy a kódolás az ilyen esetekben elõszeretettel outsourceingban történik (ld. még motiváció) Ahogy a gyártási tevékenység helyezõdik/ött át Kínába, úgy helyezõdik át a kódgyártási tevékenység Indiába és az oroszokhoz.
Én általában 2 évente próbálok meg vasat cserélni, van amikor összejön van amikor nem... attól függ mennyi khmm... kedvem van rá :-)
Bárátomat sem szabad elítélni. Nagyon szorgalmasan melózik, felnõtt létére szeret a VR világokban kalandozni, nincs más hobbija... megértem. Nem apukától kér pénzt, nem lop, nem csal. Hidd el vannak ám ilyenek is, meg persze olyanok is akik 3 havonta apuka pénztárcájában kotorásznak.
Igazából szvsz nem is baj az, hogy a hardver eszközök ennyire dinamikusan fejlõdnek... sokkal nagyobb gond a fentebb/lentebb tárgyált optimalizáció hiánya, nomeg egyes fejlesztõk erõforráspazarló hozzáállása. Persze az is világos, hogy ez is nagyban hat a hw piacra, hiszen valakinek mindig meg kell fizetnie a jelenlegi "lépcsõfokot", hogy legyen majd a fejlesztõknek mibõl megalkotni a következõ generációt. Érdekes... a konzoloknál ez valahogy sokkal jobban mûködik.
Na ott a lényeg! Azért olyan magas gépigényûek a játékok, mert az olyanok mint a haverod képesek többszázezret elb@szni a hw-re. Pont ezért. A hw gyártó megtámogatja kicsit a játékgyártót(pénzügyileg), hogy kellõen nagy gépigényû játékot csináljon. Így a hw gyártó, és az sw gyártó is jól jár, mert a sok okos pénzeszsák rohan a boltba új kártyáért. Csak az a gond, hogy azok szívják meg akiknek nincs annyi fölösleges pénzük, a gépükre. Akiknek csúcsgépük van, nem zavarja az a plusz pár százezer ft kiadás :\
Igaza van a csávónak. Anno a p166-on a kde elsõ verzióját nyúztam és azon dumáltunk haverral ,mi lesz ha 1-2 gigás procik lesznek ? mennyit fog szaggatni a linux és a prg-k. ? Nesze neked ,3gigás athlon 64 és 3 giga ram ,õszintén megmondom nem vagyok hanyatt esve tõle. Igaz stabil :)
Nem találtál ai-kat? Biztos az oblivionnal játszottál? A városokban járkál pár ember õket láttad? :) Hát szerintem megváltó, manapság a sok szar között egy jó játék...
:-) Igen, igazad van, meg nem is... van a "kinti" világ, meg a van a "benti". De mi most a "bentirõl" beszélgettünk... késõbb majd átnézek a Szabadtéri programok topicba is ígérem ;-) Ha egy mondatot kiragadsz a szövegkörnyezetbõl akkor az tényleg furcsának tûnhet. A következõ mondat tartalma szoros összefüggésben van a kérdéssel.
Már ne is haragudj, de hol találsz te az oblivionban nagyon sok ai-t? Merthogy nekem az elmúlt 30 játékkal töltött órában egyszer sem sikerült. GRafika és nagy terület pedig összefügg. Annyira pedig a nagy terület megjelenttésben éppenhogy nem jeleskedik a gáma.(Azt ahogy minden grafikai csúszka maximumra emelése után a távoli lod-olt talaj kinéz én nem nevezném elfogadhatónak) Szóval szép játék, meg jó játék, de azért ne verjük már magunkat annyira a földhöz tõle, mert nem a megváltó.
Üdv Mindenkinek! Nem pont témábavágó kérdés (az egyik hozzászólásban olvastam, errõl jutott eszembe), tudtok mondani olyan weboldalt, ahol .NET OOP-vel kapcsolatos e-könyveket találok?
Azért bátorkodtam hasonlítgatni a 2 játékot, mert anno FC szintén fejvakarásra késztette az egyszeri user-t, hogy "akkor most mi lesz... vegyek új VGA-t, RAM-ot?". Most u.e. a helyzet Oblivion esetében... ismét nagyon mélyen a pénztárcába kell nyúlni a magas minõség miatt. Van egy barátom aki a 7800GTX TOP-ot kapta ki a gépébõl és vett egy X1900XTX-et mert elege volt, hogy a több, mint félmilkás gépén csúnya dolgok történtek magas felbontáson. És ez normális dolog szerintetek? Ez pofátlanság a fejlesztõk részérõl, hogy ilyen high-end PC-k-en ilyen siralmas eredményeket produkál a játék. Persze, tudom lesz itt driver és progi optimalizáció rendesen, de nézzétek meg a HL2-õt vagy a HL-1-et. Mindkettõ a maga idejében eszméletlen magas minõséget tárt a játékosok elé és bizony még egy közepes PC-n is nagyon szépen muzsikált akkor is "ha jöttek a szörnyek" :-)
Félreértés ne essék én sem vagyok a haladás ellen. És tudom -mert én is tanultam szakközépben majd a fõsulin elég programozást-, hogy nem egyszerû dolog és könnyû dumálni... ezért is mondom, hogy olyan tervezésre és munkaerõre lenne szükség a fejlesztõi berkekben akik bizony -ha kell- képesek lemenni a programkód mélyére és -erõs túlzással- nem csak Delphiben pakolgatják a gombokat.
Szóval végre egy ember (Nicholas Negroponte) aki kiállt és felhívta erre az alapvetõ problémára a figyelmet. Remélem lesz is foganatja.
Tök egyszerû a képlet: tudni kell programozni és akkor szinte mindegy, hogy miben fejlesztesz. Bár én a tudásba azt is belevonom, hogy célnyelvet tudok választani a megoldandó feladathoz, vagy ne adj uram még azt is megcsinálom, hogy a feladatot több töredékre szedem és egyiket X nyelven, másikat Y nyelven írom... Nem nehéz, csak kell rajta kicsit gondolkodni, mérlegelni. Többnyire egy megrendelõt egyáltalán nem fog érdekelni, hogy adott programot milyen nyelven ír a fejlesztõ, tehát megvan a szabadságunk nemhülyének lenni, és több nyelven és elven is fejleszteni annak függvényében hogy melyik részfeladat megoldásához melyik a legelõnyösebb figyelembe véve a komplexitást, a határidõt, és a megrendelõ igényeit, a továbbfejleszthetõség szükségességének mértékét, stb. AGY kell hozzá és venni a fáradságot megtanulni >4 nyelven, és venni a fáradságot megérteni az újonan kidolgozott elveket és fejlesztõi eszközöket. Ennyi.
Azért a farcry-t ne hasonlítgasd az oblivionhoz, mert tökmás. A farcry egy egyszerû fps, ahol csak a grafikára meg pár fegyver egyszerûsített fizikájára, egyszerûbb ai-ra meg a hangra kell erõforrás. Oblivionban grafikára, a nagy terület megjelenítésére, nagyonsok ai-ra, meg még kitudja mi mindenre kell erõforrás. Egy program bonyolultsága nem csak a kinézetétõl függ... De az biztos, hogy az oblivion sem a leg optimalizáltabb játék :) de manapság ilyen nem is nagyon van. Legutóbb talán a crashday, volt amit egész jól optimalizáltak, mert egy gyengébb gépen is elég jól ment, akár max grafikán.
nagyon leakadtatok az oprencernel .. napi szinten hasznalok mindenfele grafikai sw-t es az adobe (mint mar mas is irta) a legjobb pelda a beleszaros cegre. az utobbi par verziojuk az osszes cuccukbol joval lassabb mint az elozoek. miert ?? mert nincs igazabol konkurencia ezert megtehetik. szerintem ennek semmi koze ahhoz, h miben programoznak ...
"Elgondolkozhatnánk azért arról is, hogy nem-e véletlenül a gépünk nem olyan gyors, mint amilyennek hirdetik? Példaképp a win98 ugyanolyan gyorsan bootol be egy 950-es gépen, mint a 3.0 gigahertzes gépemen. A win2000 is hasonlóan viselkedik. Egy 350-es p2 gépen ugyanolyan gyors, mint egy 1.7GHz-esen..."
A gepek gyorsulnak, a szoftver relativ teljesitmenye pedig kb. ugyanzon a szinten marad. Nekem anno az akkori gepemen a winnt4 is 1 perc (azaz 60 mp) alatt toltott be, mint most az xp a mai gepemen. Ez meg eppen elfogadhato.
Viszont ne felejtsuk el, hogy a mai gepek mennyivel tobbet tudnak. Az a grafikus felulet, ami 1986-ban meg csak irix-et futtato sgi munkaallomasokon ment, most itt van az uj windows-ban. (csak ott nativ gl-ben ment, itt dx-ben) Viszont a gepek ara leesett a padlo ala. Ezeket a gepeket mar meg tudjuk venni.
A fejelsztok tenyleg hajlamosak nem optimalis kodot irni, de ez regen is igy volt, csak akkor a kevesebb programozo meg magasabb tudasszinten volt. Vagy inkabb a tudas allando de egyre tobb programozo kozott oszlik el.
A windows es a linux legnagyobb baja a rossz algoritmusvalasztas es a redundans kod. Az elso a tudas es az ido hianyabol adodik, a masodik a rossz munkamegosztasbol. Ha kevesebb, de jo programozo keszitene a kodot, akkor lehet, hogy lassabban keszulne el, de jobb lenne. Ez penzugyileg viszont egyik cegnek sem eri meg. Az ingyenes es nyilt linux kozossegben pedig senkit nem lehet ravenni egy egyseges terv kovetesere.
A 100 dollaros laptop-ra pedig egy egyszerusitett szoftvert kellene felrakni, fix hardware konfiguracioval, fixen telepitett programokkal, kb. ugy mint egy mai feature phone-ok firmware-je. Ha minden program az operacios rendszer szerves resze, es jol van megirva, akkor minimalis a redundancia es ezert jobban es konnyebben lehet optimalizalni is. Ez persze uzleti alapon nem oldhato meg, de eppen ezert jok az ilyen project-ek.
Fél millás gépen elmegy..tök jó! :-DDD Holnap énis megveszem a játékot! :-DDD
Lehet ám ott nem a kóddal volt a baj, csak a hozzá nem értéssel.:-DD Láttam én is olyan érdekes játékokat, hogy mondván a videókártya még nem tud tömöríteni ezért zúzzunk bele pár nagyfelbontású BMP-t, meg zene is kell, de legyen kicsi, rakunk bele MP3-at. Aztán gallyra is ment a progi, MP3 és a több 10000 soros progi megette a procit, kép+ a memóriáról gondoskodott. És lehet, hogy a programozó tudna jót csinálni, csak tényleg a még közepes cégeknél ott vannak a megmondó emberek és õk ugye mindenkinél okosabbak.
Ja és ingyenes, nem kaszálok vele milliókat, noha 3 hónapomba került. A legtöbb idõt a 3000 kifejezést tartalmazó adatbázis vette el. :-(
Nya.:-D Leendõ programozók nevében.:-D Szal 1 HTML oldal manapság nem elég a sikeres vizsgához! Nézd meg az oldalam, van rajt 1 1,6MB-os és egy 7MB os progi/az utóbbiban van 5 perces mp3 háttérhang gyanánt/, progi. Az oldal és a progi egyben vizsgamunka. Frissítés detektálás, animáció + elég sok apró dolog van benne, és cakom pakk 2000 sor volt, nincs optimalizálva mert nem tanultuk, egyszerûen nem követelmény. Meg tudom csinálni mobil telókra is, készül 1 olyan verzió is, de az más tészta. Na mind 1. leendõ programozók védelmében csak ennyit akartam írni.:-)
Jaja. :-DD Nézi a promptos képernyõt, és mondja " Most, most lõjj! Ott az If elágazásnál 2 ciklussal vissza!" :-DD Amúgy lehet kicsi és gyors meg jó progit írni, pl C-ben, az is grafikus felületre is megoldható, csak oda ugyebár tudás is kell és nem kevés ráfordított munkaóra. Nem ám mint a Magic "programnyelv" ahol 2 hattintás és kész a progi, de még 1 számológép is 4MB.:-) Középútnak ott a Delphi, Visual Basic, Visual C. De akkor ezekhez is érteni kell, és tapasztalatból tudom, hogy egy programnyelvet sem lehet szõrõstül bõröstül megtanulni 2 év alatt sem, hogy pl minden fügvényt tudj mire való, hogy lehet optimalizálni, stb. Amúgy a jõhõ kilátásai szarok ezen a téren. Mármint készülnek azok a proginyelvek ahol már nem kell programozni tudni! Legonak van már ilyen fejlesztõ készlete. A piros bigyót a zöld bigyó mellé húzod+ kap 1 kis kék háromszöget és hopp kész a progi. Ezt szerintem az USA-nak találták ki. Vagyis az analfabétáknak, de terjedõben van. Úristen mi lesz itt 3-4 éven belül...
Nem tudom, mit kell akkor ennyit senyvedni, ha nincs jó progi, Írjon ki a manus valami jó pályázatot,( a 100$l.top oprendszerére) és a készítõ(k) nevét megismeri így a világ.. akár még valami win-lin konkurrencia is lehetne belõle....
Persze, ezzel a magunkfajta bõven megelégszik. De a HC gamerek már 1-2 éve csak röhögnek az 1024x768-as felbontáson. És ahogy te is írtad, "ha jönnek a szörnyek...". Nem tudom elfogadni, hogy az ember megvesz egy 400 ezres gépet amire 2 héten belül kiadnak egy olyan optimalizálatlan -bugos- progit, ami állóképeket képes produkálni esetenként.
Persze igazatok van... pénz, pénz, pénz... vegyé' új gépet, ha... vegyé' több ramot ha... Olyan jól elvoltam a C64-el anno :-) Nem tudom emlékeztek-e rá, de nézzetek meg egy demot/játékot a gép kiadását követõ 2. évben és nézzétek meg, hogy u.o. hardver mellett milyen döbbenetes munkák születtek. Bár nem ide tartozik, de mégis idevág: optimalizáció magasfokon amit a PS2-es programerek is elkövetnek. Eleinte is komoly megoldásokat lehetett látni a gépen, de 1-2 éve meg már az ember azt mondaná, hogy ez egy PC-s high-end gépen futó nextgen progi. Kár, hogy csak a konzolokon van meg ez a sokat vitatott jó szokás :-(
Ez is egy kib****tt üzlet lett. Régen volt 4k demó meg 64k-ban játék. Ma a doom3 egy mentett állás 19Mb! Az optimalizálás nem üzlet. Ennyi.
Elgondolkozhatnánk azért arról is, hogy nem-e véletlenül a gépünk nem olyan gyors, mint amilyennek hirdetik? Példaképp a win98 ugyanolyan gyorsan bootol be egy 950-es gépen, mint a 3.0 gigahertzes gépemen. A win2000 is hasonlóan viselkedik. Egy 350-es p2 gépen ugyanolyan gyors, mint egy 1.7GHz-esen...
macros:
azért lássuk be a Vista hw igénye egy vicc. Fõleg a linuxos XGL mellett aztán végképp. (az elfutkos korrektül egy 800 -as p3 -on, gef2 32 BM-al, es 256 memóriaval)
OFF: Oblivion 7800GT-n kifogástalanul megy 1024x768-ban 3.5-ös Athlon+2Gb. Az önárnyék, stb. be van kapcsolva +HDR, meg a grass distance csutkára fel van nyomvan: így tökéletesen játszható (kivéve az erdõ közepén, ha jönnek a szörnyek).
Nem is rossz ötlet. A BeOS pl ilyen célorintált kis gépekre kiváló OS lenne. És azért egy P200-on 64 MB ramaml nálam már mûvelt csodákat. (6 mp3 egyszerre lejátszása akadás nélkül pl:)
Akármennyire is divat az MS-t fikázni meg lelamerezni, ennek ellenére tényleg csak a legjobb kóderek kerülhetnek be oda. Azt meg tudomásul kell venni hogy a programozó azt csinál amiért fizetik, ha szart kell, mert mondjuk Billy / Ballmer megaszonta, akkor azt. Nameg amikor jönnek hogy "legyen benne hát olyan kis izé bigyó ami pörög, forog", na azt kódold le optimálisan! :D
// Oblit majd kipróbálom, 7900 gt-vel, 85.25 forcewarezzel talán jó lesz. :)
Ja, és mindenki menjen a faszba, aki assemblyben akar olyan alkalmazást írni, ami fut clusteren. De most komolyan. Mi ez itt? Óvoda?
MUHAHAHHAHAA EZ JUTOTT ESZEMBE:
Rosszabbak a programok, mint 4 éve ::)))))
Azert a MenuetOS-t nem kell tullihegni. Nagyon is kiforratlan, raadasul elinditottam a grafikus demo prg-t (valami forgo cucc volt) 2 peldanyban, es fele olyan lassan futott, mint 1. Na most hany eves is az a projekt? Es nem egy emberes project, legfeljebb ugy, mint a SkyOS. Es csak hasonlitsd ossze a kettot... Assembly jo dolog volt, ma is megvan meg a helye. Egy OS irasa nem ide tartozik.
Viszont az igaz, hogy manapsag tenyleg sok a bloat. Oke, unicode szoveg, divx, stb., de azt nem lehet tagadni, hogy igenis rengeteg felesleges hulyeseg terheli a mai rendszereket. Ez nem az OOP hibaja, hiszem az meg az a szint, ami szukseges, raadasul pl. a Java VM az minden kiadassal gyorsabb lesz. Hanem a felelotlen fejlesztes.
Valoban tessek megnezni a BeOS-t, lehet, hogy ma mar nem lenne eleg, de annak idejen siman lenyomta barmelyik masik OS-t teljes OOP mellett. Szerintem inkabb azt kene rakni ezekre a 100$-os gepekre, legalabb lokest adna a Haiku-nak is...
"Az MS-t kár volt belekeverned, ott épphogy a legjobb programozók dolgoznak."
A legjobbak... fõleg OOP-ben ;-)
Amúgy mondhatnám az összes többi progit is ami "népszerû"... 1-2 játéknál veszik csak a fáradtságot, hogy optimalizáljanak. Meg sem engedném, hogy olyan waret dobjanak a piacra ami kolosszusként rátelepszik a vasra.
Far Cry-t pl. nagyon szépen optimalizálták... talán 40%-al jobban fut, mint 4 éve ugyanazon a konfigon... igen, megcsinálták!
De ellenpéldának jó az Oblivion ami ugye a mai PC-s gamer vágyálmából a feltelepítést követõen hamar rémálommá vált. (Ezen a konfigon /nem az enyém/ is képes 20 FPS-t produkálni: 3.4-es LGA775, 2 Giga Crosair 667, X1900XTX, sata). Na ez tökéletes példája a nem optimalizált terméknek. Nem szép dolog ilyet piacra dobni
1. Manapság annyi fejlesztõ van, hogy a cégek bõven tudnak válogatni. Egy felvételi beszélgetésbõl + hozott referenciákból kiderül hogy az illetõ hülye e. A hülyéket ma már nem veszik fel: max. más hülyéknek fejlesztenek weboldalakat Biszbasz Bt. néven. 2. Szerintem az optimalizáció nem a fejlesztõ dolga (hozzátéve azt is hogy a multam miatt én speciel imádom optimalizálni a kódjaimat: ha van rá idõm mindig elszórakozom vele), hanem a fordítóprogramé. Például a Javában alapvetõ hiba hogy ha a stringeket '+' jellen összeadjuk és nem egy tömbbe pakoljuk és aztán kiolvassuk a végén. Kérdem én ezt miért nem a fordító végzi önálóan? (tudtommal pl. a JBuilder ezt magától megteszi). Ez inkább a fordító fejlesztõinek lustasága, nem pedig a programozó hibája.
2. ne akarjál assemblyben oprendszert írni. Van olyan (Menuettos), de nincs értelme, mert nem portolható sehova, csak szórakozásból van.
Nem biztos, hogy önmagában csak az OOP hibás. A legjobb példa rá az EPOC32 oprendszer, ami a Psion series 5-ben volt. Vagy a BeOS. Szóval lehet OOP-ban is kis erõforrásigényû hatékony kódot írni. Csak ki kéne venni belõle a szemetet.
Az MS-t kár volt belekeverned, ott épphogy a legjobb programozók dolgoznak. De sok a manager, a megmondóember. A linuxról meg számtalanszor bebizonyosodott hogy ugyanolyan erõforrásigényes, védtelen mint a win, csak azért nem hekkeli meg senki, mert senkit nem érdekel. Most jöhet a duma hogy de van 1 cd-s linux is, winbõl is van tinyxp, ezek minde lebutított verziók, pont annyival kisebbek mint amennyivel kevesebbet tudnak.
Egy-két ember szerintem picit félreérti a cikket. Itt senki nem arról beszélt, hogy gépikódban kellene közvetlenül a programokat megkreálni. Itt arról van szó ami már tényleg baromi terhes mindenki számára... az optimalizáció hiánya!
Tényleg tarthatatlan az az állapot, hogy manapság -már bocsánat- de minden marhából lehet programozó, aki kiböffent magából egy HTML oldalt. Ennek meg persze az a következménye, hogy a t. programozó urak csak a "bátyám szobatársának a barátnõjének az apjától hallottak a gépi kódról", beülnek a bõrfotelbe és egy egyszerû adatbáziskezelõt kihoznak 200 megából full OOP alapon... bezsebelik a nagy lét.. a kérdésre pedig, hogy miért ilyen cefet lassú azt a választ adják, hogy nem a progi lassú hanem a géped szar... vegyé' jobb procit, több ramot, gyorsabb vinyót stb.
De tudjátok mit legyen... engedjük az ilyeneket is kibontakozni, de a szörnyû az, hogy a nagy cégekhez bekerülve ezek az emberek a remek hozzáértésükkel tovább növelik a populáris programok bonyolultságát. Ilyen 50 millió kódsorról regélnek Vista kapcsán... bah... röhejes.
Ha olyan szívvel, lélekkel meg olyan tudással rendelkezõ programerek ülnének "fontos székekben", mint akik 64k-ba képesek kisebb csodákat létrehozni, akkor nem tartanánk ott, hogy a 64 bites 3.2-es procim, 2 Giga ramom és SATA vinyóm mellett több, mint 1 percet várok mire ez a szemet bebootol.
Ja tudom, ébredjek fel... meg choose Linux (az is van, szalad is szépen :-)
Nem tudom, hogy van-e benne jogosultsági ellenörzés, vagy hogy akarnak-e beletenni, ha nincs. Na meg az is kérdés, hogy ha beletennék, akkor az mennyit lassítana a rendszeren, ha azt is jól optimalizált assembly kódban írnák meg. Mindenesetre jelezetem, hogy én ezt csak példának hoztam fel az optimalizálásra és az assembly-ben való fejlesztésre, nem pedig etalonnak ami tökéletes és követendõ.
Naigen, amikor megkapod a határidõt hogy x hét alatt legyen kész a progi, akkor kevésbé érdekel hogy optimális a kód vagy sem, te az elkészülésre kapod a fizetést. :)
Lehet hogy kicsi, meg gyors, de ezért cserébe nyilván nem is végez olyan jogosultsági ellenõrzéseket, amik ma már fõleg hálózati munkáknál elképzelhetetlenek. Az ilyesmi viszi el a többi oprendszer idejének jó részét is, hiszen semmi nem fut csak úgy magától, 0 erõforrásigénnyel.
Az oop-re szükség van, egy nagy prodzsektet nem lehet papír-ceruzával, adhoc alapon kódolni, mert csak egy nagy bughalmaz lesz belõle. Fõleg ha valamit módosítani kell rajta, és millió helyen kéne változtatni.
A java, c# meg az oop-n kívül azért is jók, mert platformfüggetlenek, nem kell minden gépre külön a saját assemblyjében megírni, ugyanaz jó mindre, tehát többfelé fel lehet használni.
"Assemblyben nyilván lehetne tök optimális, gyors és kicsi oprendszert írni, csak mondjuk egymillió emberév munka lenne."
Ebben azért nincs igazad. Ajánlom a következõ oldalt: http://www.menuetos.net/ Ez egy 100 %-ban assemblyben írt oprendszer. Mostmár csak a 64bit-es verziója tölthetõ le, de van neki 32 bites is én is azt szoktam használni. Ahhoz még mellékelték a forráskódot is. Egyetlen floppyra ráfér. Kezeli a hálót, van webszervere, full grafika minden nem kell shell-el pöcsölni. Még most is hihetetlenül szokatlan, hogy elindítva egy programot, abban a pillanatban elindul, nem kell a forgó homokórát bámulni, mint más rendszereknél. Egyetlen programozó írta az egészet és két másik besegített a net és grafikai részbe és nem egymillió évig készült. Nem feltétlenül azt akartam ezzel mondani, hogy ez a jövõ útja, csak éppen egy példa arra, hogyan lehet kicsi, villámgyors, ugyanakkor mégis komplex programot vagy rendszert írni, akár egyetlen programozónak is.
Ez igaz, de ha oop-ben programozunk, akkor lehetne alatta a hw is olyan ami natívan támogatja azt. Régebben akartak Java processzort csinálni, nagyon nem hallani már róla. Lehet hogy egy mûveletet lassabban hajt végre mint egy x86, de ott egy mûvelet igen sok x86 mûvelettel ér fel, összteljesítmény szempontjából mindenképp hatékonyabb lenne egy ilyen "célprocesszor". Igaz, ehhez az is kéne hogy megállapodjanak az assembly utódáról, mert az se lenne jó ha minden proci más nyelven mûködne, azzal ugyanott lennénk mint most.
Ellenpelda: En Photoshopon is dolgozom evek ota, es minden egyes resz joval lasabb az elozonel. A csucs a mostani CS2, ami jocskan lomhabb a CS1-nel. Pedig nincsen benne tobb csilivili, egyszeruen optimalizalatlan, bugos is... A lenyeg hogy a programozoknak minel gyorsabban kell atalakitaniuk az egeszet, hogy ujnak tunjon.
Egyébként a #2-re annyit reagálnék hogy igazából ma már nem számítanak ezek a dolgok az esetek 95%-ában. Nagyon kevés sebesség kritikus dolgot kell manapság írni (algoritmusok fõleg), a futás nagy része így is a felhasználóra / hálózatra / adatbázisra való várakozásra megy el. Mondjuk én az utóbbi öt évben kizárólag web közeli fejlesztéseken dolgozom.
Persze ha kernelt írsz, az más tészta, viszont az már nem a .Net és a Java hatásköre.
Részben egyetértek az elõbb hozzászóló programozó úr véleményével. -A linux kernel továbbra is sima c-ben készül. Hát esküdni nem mernék de szerintem nem sokat romlott sebességben az elõzõ szériákhoz képest. Nyilván egy 64-bites utasításokat mindenféle piciX-es - satas, tûzvonalas, usbos kernel NEM LEHET kissebb mint egy 1.0 széria. - Nicholas Negroponte eltévesztette a konferenciát. Szerintem a kis buta windowst abból a Vistat rakta fel az uberszuper masinára.... Izé miért is vesz 100as úr halál drága notebookot?????? Miért nem a 100 dolcsis laptopot vett. - Linuxon a 100as úr nyugodtan használjon XFCE-t, mc, vi. Ezek még az 5 évvel ezelötti note-okon is hasítanak. A 7-8 éves gépemen remekül megy a Stable debiannal. Igaz a firefox 15sec alatt áll fel rajta, de internet elõtétnek használom, arra jó. - Ha valakinek baja van a KDE,Gnome openoffice és társaival nyugodtan használjon mást.
"Már akkor megkérdeztem, hogy mire is jó ez az OOP ha nagyobb kódot fordít, és lassabban is fut."
Én most nem vállalnám fel azt hogy ezt elmagyarázzam neked. Ha veszel / letöltessz egy OOP könyvet és megpróbálsz magadon erõszakot elkövetve megírni pár OOP programot (az OOP elveknek megfelelõen) akkor magadtól is rájössz, ha meg nem, akkor egyébként sincs segítség.
Én Z80-on kezdtem, 80286-on folytattam, 386-on írtam MMX alá grafikai rutionokat, aztán programoztam mindenben ami mozog, most mégis Javát, AJAX-ot és .Net-et használok. Hogy miért? Mert könnyebb újrahasznosítani a kódot, mert sok mindent megcsinál más - és én erõfeszítések nélkül átvehetem tõlük az eredményt, mert könnyû debugolni, mert a fejlesztõeszköz kinyalja a seggemet (VS 2005, Eclipse 3) és mert pár hét alatt kell komplex programokat letennem az asztalra.
Ha neked jó keseregni azon hogy már nem kõbaltával dolgozunk, csak tessék. Ifjú titánként még én is az Assembly programozásért tüntettem (akkor a C volt a puhapöcsûeknek való). Majd ha idõsebb leszel másként fogod látni.
Informatika és tudomány
Naigen, amikor megkapod a határidõt hogy x hét alatt legyen kész a progi, akkor kevésbé érdekel hogy optimális a kód vagy sem, te az elkészülésre kapod a fizetést. :)
