Úgy vélem, Te elsősorban nem szimulátort szeretnél alkotni, hanem a programozást élvezni.
Jól látod!
Bár a kettő nem zárja ki egymást. :)
Én is remélem, próbálok olyan feladatok kitalálni magamnak, ahol a hasznosság és a programozás élvezete (két eltérő szempont) nem nagyon üti egymást.
Milyen nyelven írod?
C#-ban írom. A grafikához az OgreDotNet-et használom, ami egy .NET-es wrapper az Ogre3D grafikus engine-hez. Más külső könyvtárat a .NET alap osztálykönyvtárán kívül nemigen veszek igénybe. A fizikát megírom magam; szerintem nem lenne sokkal egyszerűbb egy külső fizika könyvtárat testreszabni, mint írni egyet a speciális autószimulátoros igényekhez, és így a perfomanciát is jobban kézben tudom tartani.
Én is így gondolom, bár a google-on keresve egyelőre nem sikerült ilyet találnom. Amin meglepődtem, mert a dolog elég kézenfekvő. Ha netán nem lenne még ilyen, akkor a kérdés az, hogy azért, mert nincs rá igény, vagy annyira nehéz jól megcsinálni?
Ha mindenképp szeretnéd megcsinálni, akár karakteres módban el lehet kezdeni 1-2 szabállyal.
Igen, már elkezdtem. Nem karakteres módban, de valóban elég sok mindent leegyszerűsítettem azért, hogy viszonylag gyorsan tudjak valami prototípust csinálni, miközben egyben feltérképezem a feladat nehézségét. A grafikával pl. első körben nem is nagyon foglalkozom, 3D-t használok ugyan, de a prototípusban egy autó egy téglatestként jelenik meg:) Az utak, útszakaszok, kereszteződések logikai szerkezetére, útszakaszok geometriájára, a többi autók A.I.jére, és a KRESZ szabályok modellezésére helyezem a hangsúlyt.
Eddig úgy tűnik, hogy nem egyszerű a feladat, de azért szerintem kezelhető. Szép kihívásnak tűnik.
Nagyon valószínű, hogy létezik ilyen program. Játszottam pár játék célra készült repülőszimulátorral, de nem sokkal lettem tapasztaltabb, bátrabb. Ha igazi gépbe kéne beszállni, gyakorlatilag nulláról kellene elkezdenem.
Ha mindenképp szeretnéd megcsinálni, akár karakteres módban el lehet kezdeni 1-2 szabállyal. Így képet kapsz a feladatban rejlő lehetőségekről, korlátokról.
Ez nagy elégtétel lehet azokhoz az időkhöz képest, amikor még a Windows API-val kellett szenvedned, és a teljesen obejktumorientálatlan CreateWindow-t, ShowWindow-t, meg a társaikat kellett használnod...
Egyébként ha nem is használok OO oprendszert, én már legalábbis programozás közben, nagyrészt OO rendszereken keresztül érem el a számítógép legtöbb funkcióját. Gondolok itt pl. a Java osztálykönytárakra, és a .NET-re.
Csak mert eszem ágában nem volt, nincs, és nem is lesz oprendszert fejleszteni, nem is utaltam rá, hogy lenne, sőt többször kifejezetten kiemeltem, hogy én biztos nem fogom erre elkúrni több évemet fölöslegesen. ...:)
Egyébként persze most is van aktuális ötletem. Megosztom veled, hogy min gondolkodok most éppen:
Olyan szoftvert akarok fejleszteni (ezt tényleg meg akarom csinálni, sőt el is kezdtem már), hogy van egy olyan autószimulátor, ahol nem versenypályán kell száguldozni, hanem a KRESZ szerint kell vezetni egy városban. A szoftver gyakorlatilag úgy működne, mint egy gyakorlati vezetés vizsga, számolja a warningokat, és a hibapontokat: vagyis automatikusan észreveszi a hibákat, az elsőbbség meg nem adástól kezdve a behajtani tilosba behajtáson keresztül a megállni tilos tábla figyelembe nem vételéig. Ez nem is igazán játék lesz, hanem vezetésoktató program. Van már ilyen szerintetek? Mennyire nehéz megcsinálni szerintetek?
Kepzeld nadamhu, szerintem stpmod-nak fogalma sincs arrol, hogy mit beszel, benyog beszolasokat, de nem ereszkedik le hozzank, hogy szakmai ervekkel vedje meg azokat.
Na jólvan mentôkérdés:
Szerinted mi a francért használnak:
-Corbát
-Com-ot
-JAVA-t
-.NET-et
(A UNIX kialakulásakor egyik sem létezet...)
Tetszik nekik a object.method() típusú írásmód? Lol.:) (Képzelem, amikor a CORBA kitalálója, vagy a C++ kitalálója ellen felhozzák, hogy mi van komám, tetszik az object.method() típusú írásmód?)
Egyébként pedig OCCAM borotvája szerint tetszik az olyan egységes, egyszerů írásmód, amilyen lehetséges.
hogy olyan valaki kezdett bele ebbe, aki most ismerkedik az objektumorientált szemlélettel, és tetszik neki az object.method típusú hivatkozás Ez aranyos:) Nekem meg az jött le, hogy neked az objektum orientált szemlélet annyit jelent, hogy method(object, ...) helyett néha azt írjuk, hogy object.method(...). Kár, hogy az OO mögöt filozófia is van. Akik ezt nem ismerik fel, azok szoktak királyul tipikus C programokat írni pl. C++-ban. (Ne félj, én is így kezdtem:))
Ennél ugyanis több konkrétumot a vitaindító maga sem igen mondott. A 74-es hozzászólásomban, mondtam konkrétumot. Ennél több konkrétumot minek mondjak? Láthatólag vannak akik sejtik, hogy mire gondolok, illetve vannak akik nem látnak az egész témában semmi fantáziát. Elmondanám, hogy ez egy fórum. Az ember ide általában nem kódot írni jön, legalábbis én azt nem a fórumon teszem. Ennél konkrétabb meg az lenne, ha évekig fejlesztenék egy OO oprendszert, és beraknám ide a forrását. Sebessség és usability teszteket csinálnék. Sôt, elôfordulhatna, hogy csak 5-10 év után rúgna labdába.
Oprendszert fejleszteni tehát nem áll szándékomban, túl nagy falat lenne ilyesmibe belekezdeni. Viszont vannak elképzeléseim, amit néhány technológia fejlôdésébôl vontam le (ilyen pl. a JAVA technológia meglepô sebességbeli fejlôdése.)
Teljesen jól érzed. Eddig csak azért nem folytam bele tulságosan, mert elolvastam az elejét, és az volt az érzésem, hogy olyan valaki kezdett bele ebbe, aki most ismerkedik az objektumorientált szemlélettel, és tetszik neki az object.method típusú hivatkozás. Ennél ugyanis több konkrétumot a vitaindító maga sem igen mondott.
Ha most sem fogod megérteni, akkor inkább menj segédmunkásnak, ott semmi nem bonyolult.
Nem mindegy, hogy egy rendszer összes elemeobjektumként érhető el, vagy csinálunk egy objektumrendszert, amin keresztül elérhető a rendszer összes eleme.
Erre mondtad hogy azonos filozófia. Én meg azt, hogy azonos ja, csak más teljesen.
Aha. Csak teljesen más filozófia :) Nem mindegy, hogy valami elérhető mint objektum, és minden ami egy adott rendszerben van ilyen módon kezelhető, vagy minden szir-szar elérhető egy újabb szir-szar-on keresztül.
Az az egész filozófiája, hogy szinte minden koncepciót, amiről a rendszerben beszélhetünk, a kernel felügyel Javítás:
Az az egész filozófiája, hogy szinte minden koncepciót, amiről a rendszerben beszélhetünk, objektumnak tekintünk, ezeket a kernel egységesen felügyeli, és a kernel is objektumnak tekinti ôket.
Egy kis agymenés:
Ha valaki egy ilyen jellegű OS-t kezdene fejleszteni, arra az aktivitásra legalábbis kiváncsi lennék:
Egy Object Host célszerűen egy számítógép / egy OS példány.
Egy Object Host:
- object instance-okat
- 'class leírásokat' (type library)
- és threadeket
menedzsel, tárol.
Egy objektum adatai illusztrációnak legyen ilyen: (a konkrétumok itt illusztrációk!)
{
Objektum id: 64bit
2 részből áll:
32bit: Object Host Id (pl. IP cím adott esetben...)
32bit: Local Id
Objektum osztálya (string: pl. 'a.b.com')
}
Felmerülő kérdések:
- A 'thread' és az 'osztály' objektumnak minősül-e (érdemes - e bevezetni a Class és
a Thread speciális osztályokat. Valószínőleg igen, de ezeket a kernel azért speciálisan (is) kezeli.)
A kernel nagyon magas szinten van, tehát a következő dolgok alulról kapcsolódnak a kernelhez modulárisan, mintegy 'driverek'-ként:
- a tárolórendszerek (Olyan mint a winchester, adatok perzisztálására képes. A kernel által szerializált objektumok időnként itt találnak menedéket...)
- kommunikációs közegek. (A kernel által szerializált objektumok ezeken keresztül közlekedhetnek a HOST-ok között...)
- egyéb 'driver-ek'.
A kernel egységes hozzáférési szisztémát alkalmaz object szinten, ami hasonlít a fileok
hozzáférési jogosultság rendszeréhez, de egyben leírható benne a programozási nyelvek
public private megkülönböztetése is. Ettől az egységesség az egészben lényeg, ettől várjuk, hogy hátha 'így majd nekünk jó lesz'.
Az objektumok között természetesen öröklődés lehetséges, minden metódus virtuális.
Az az egész filozófiája, hogy szinte minden koncepciót, amiről a rendszerben beszélhetünk, a kernel felügyel. Ettől lesz a rendszer objektum orientált, ez szerintem nem üres frázis.
Egy ilyen kernel feladatköre jól meghatározott. A kernel kicsi. Felfogható mikrokernelnek is. Mégis viszonylag sok mindent
tud az objektumokról, hiszen közvetlenül felügyeli őket: Tehát jó heurisztikákkal remélhetőleg extrémen jól optimalizálható a mai vasakon.
A heurisztikák így első blikkre többek között főleg arra vonatkoznak, hogy kit hol miért és hova szerializáljunk,
(felfogható ez egyfajta object caching-nek is, amit jól kell illeszteni a számítógép cache hierarchiájához. (A belső cache-tól a winchesterig bezárólag.))
...Így ér össze a hardver az objektumokkal, a file koncepció nélkül. Aztán felébredek, és beleér a kezem a bilibe... :))
"A fajltipusok kozott orokles? Ilyet azert nem hasznalnak, mert senki nem ult neki megtervezni egy ilyen hierarchiat -- fokent mert nem volt ra szukseg. Olyan szinten mindenkepp, amit az OS erint. A _tartalmat_ tekintve legalabbis."
Erdekes, hogy ezt mondod, a Longhornban meg fog jelenni egy uj filesystem (szinten retegesen - az NTFS fele), amely pont ilyesmit fog csinalni, peldaul tipust, schemat kot a filehoz, es definial par lehetseges asszociaciot a 'fileok' kozott, mint pl. a link, embendding, stb. Ez az uj filesystem a WinFS lesz. Tulajdonkeppen mar gondolkodtam en is azon, hogy a file mennyire alacsony szintu, 'gyenge' eszkoz, eleg nyilvanvalo az intellektualis igeny a kiterjesztesre, viszont erdekes kerdes, hogy lesz-e igeny a file fogalom 'megerositesere'.
Semmivel sem lesz a program bonyolultabb, mint eddig.
Ja és az általad adott példában kb. semmi újat, semmi hasznosat nem nyújt az a filozófia, amit ebben a topicban pedzegettem. Azért, mert már a feladat is (#include) a fileok fogalmi körével dolgozik. Egy adott kidolgozott fogalmi körben megfogalmazott feladatra nem mindig húzható rá hasznosan egy másik fogalmi kör megoldása.
Pl., ha olyan feladatokat adnál, ahol a processzor regisztereivel kell feladatokat elvégezni (EAX, EBX, stb..), akkor pl. semmi hasznát nem látnád egy strukturált, nem ASSEMBLY szintů programnak.
Tehát tanulságként levonom: az általam feltett kérdés tulságosan mélyfilozófiai lett. Minden rendszer mögött kell, hogy legyen filozófia. A UNIX mögött az, hogy minden file. én olyasmirôl beszélek, hogy minden objektum. A file és az objektum nem ugyanazok a fogalmak, nem ugyanúgy kell ôket kezelni sem. Ha ugyanazok a fogalmak lennének nem használnánk 2 szót rájuk. Azon vitázni, hogy melyik a jobb filozófia (minden file vs. minden objektum) tényleg parttalan lenne.
Szerientm ez mer reg igy van. Legalabbis nagyon csodalkoznek ha a Win2k3 nem erre epulne. A regebbi rendszerekben is az APIk egy jelentos resze COM, pl az egesz DirectX, a shell api es meg jo sok. Hmmm, valószínůleg igazad van, elég keveset használtam COM-ot, és a Windows felépítését sem ismerem nagyon. Ezekszerint végül is a topicnyitó kérdésemre választ adtál, tehát a Windows a COM-al tendál valami olyasmi felé, amire én gondolok.
Ezt a hozzászólást nem is vettem észre... mi a nem megszokott abban, hogy az egyik process indít egy másikat, azután vagy megvárja a befejeződését vagy nem? Amióta multitaszking van, ez bevett dolog...
>Az én kérdésem az, hogy az egy valid eképzelés-e, hogy egy ilyen COM, vagy CORBA jellegů rendszer belefészkeli magát az oprendszer belsejébe
Szerientm ez mer reg igy van. Legalabbis nagyon csodalkoznek ha a Win2k3 nem erre epulne. A regebbi rendszerekben is az APIk egy jelentos resze COM, pl az egesz DirectX, a shell api es meg jo sok.
Ami ennel erdekesebb, hogy sok nem OS program is beszall a buliba, ugyhogy nyitott kapukat dongetsz.
>Az egységes szemléletmód, egységes szintaktika sokat jelentene. Többek között egy egységes dokumentációt.
Nemtom ki hogy van vele, az en elvarasom hogy a dox legyen preciz es legyen benne minden info. Hogy mellette milyen a szrekezete erdektelen. Es a gondok az elozo elvaras hianyabol jonnek. Az MSDN-ben ott van egymas meleltt a Platform SDK es az Office SDK, elobbi ugye a "klasszikus" formaju a masik meg OO, de nem tapasztaltam hogy barmivel jobban lehetne az utobbibol dolgozni.
>A rendszer gyorsabb megismerését.
Ez meg sokkal inkabb azon mulik hogy valaki tenylegesen RTFM -- ugye tokmindegy milyen a dox amit nem olvas el az illeto, vagy csak par sort a sok oldalbol.
>Az egységesség, és az objektumok kerneleben kezelése performance elônyökhöz is vezethetne. (Pl. nem szerializál a rendszer, csak ha végképp muszály, stb...)
Ez meg vegkepp nagyon regota igy van, sot ha nem megyunk szorszalhasogato modba, akkor mondhatjuk mindig is igy volt. A handle-k amikkel az oprendszerek szorakoznak es a hozzajuk renelt hivasok minden praktikus szempontbol objektumok. Csak le vannak tuzfalazva a juzer iranyaba.
>A filetípusok öröklési hierarchiája nagyon fontos. Hiába mondod, hogy nincs különbség: az eddigi oprendszereken valahogy nem lehet megoldani ilyeneket:
A fajltipusok kozott orokles? Ilyet azert nem hasznalnak, mert senki nem ult neki megtervezni egy ilyen hierarchiat -- fokent mert nem volt ra szukseg. Olyan szinten mindenkepp, amit az OS erint. A _tartalmat_ tekintve legalabbis. Az struktura meg van oldva, ott az ole-compound-file, amihez csatlakoznak a gyari interfeszek. Es a legtobb COM objektum ilyet hasznal a sajat dolgaihoz. Es nem latom semmi akadalyat, hogy egyre specibb interfeszek feluljenek a fajlra, csak minek tennek?
A gyakorlat az, hogy egy *objektum* tud sok interfeszt, a fajl meg csak a perzisztencia eszkoze. Igy az eredeti problemadat (pl. tobbfele formatumu kep meretezese) meg lehet oldani.
>Mivel a rendszer nem gondolkodik öröklôdésben, a fejlesztôk sem gondolkodnak abban, hogy a Documentum az olyan valami, ami valahány oldalas.
Foleg azert, mert a "dokumentum" legalabbis ami nekem eszembe jut a fogalomrol csak nagyon enyhen kapcsolodik az "oldal" fogalmahoz, egy jelentos reszuknel ez teljesen ertelmetlen, a maradeknal meg tovabbi dolgok tomegetol fugg a hanyoldalassag.
A hierarchianak ugye nagyon lenyeges eleme az LSP ("is a" elv), emiatt nem igazan tudod hova berakni az ennyire ad hoc dolgokat.
Az egesz buli ararol nem beszelve -- ha kitalaltal egy interfeszt amit illik implementalni, mint pl. az oldalak megszamolasat, vagy a kep atmeretezeset, ki csinalna ezt?
>mindeki által elfogadott objektum-hierarchia
Na ez itt a kulcsszo. ;-)) Ehhez ket dolog kell, egy proposal, ami definial egy ilyen hierarchiat, aztan pedig hogy "mindenki" erre bolintson. Ha ennyi megvan, mar egyszeru lenne kivitelezot talalni.
Ha a Java virtual machine és futtatókörnyezet kifejezetten a kernelben lenne, és optimalizálna olyan dolgokat, amiket eddig azért nem lehet, mert nem minden Oprendszeren můködne jól, akkor nyilván gyorsabb lenne.
Miert, van ennek barmi akadalya? Marmint hogy a JVM alatt ne legeyn semmi mas csak a vas? Ha jol remlik a Sun csinal PicoJava procit si, ami a bytekodot futtatja (vagy akart ilyet csinalni), hogy gep is legyen korulotte nem lenne nagy buli, plane ha ugyanaz a Suncsinalja, aki Solarist is csinalt. Szoval ilyen nagy valoszinuseggel letezik, vagy ha nem, akkor komoly piaci oka lehet.
[Amugy nem hinnem hogy a java sebessegebol nagy szeletet jelentene a jvm es a kernel kozti kommunikacio. De errol nyilatkozzon inkabb valaki javas.]
Mégegyszer megpróbálom, mivel türelmes állat vagyok;)
C fordító a "pufdef.c" fordítása során oda érkezik, hogy #include "pufdef.h" Ekkor egycsapásra mit csinál?
