3d op. rendszer
2010-01-30T20:07:39+01:00
2010-02-01T07:52:06+01:00
2022-07-25T07:06:17+02:00
  • 3. Mozgatás / átméretezés:

    Szóval, szvsz nem nagy varázslat.


    Mutasd a teljes hozzászólást!
  • Amit én gondoltam nem tetszik senkinek?


    senkinek...
    Mutasd a teljes hozzászólást!
  • Amit én gondoltam nem tetszik senkinek?


    De, ötletes megoldás, csak van benne egy hiba, amit te is írsz, de ha már lerajzoltam ASCII-ban, akkor már postolom:

    Tegyük fel, hogy egy vízszintes ablak felett van egy függőleges, ami pont ugyanoazon az x koordinátán végződik:

    +-----+ | | +---|-----+ | | * | | | +---|-----+ | | +-----+

    Ekkor a *-al jelölt pontra érkezve az algoritmus azt fogja hinni, hogy a vízszintes téglalapot kell továbbrajzolni.

    Persze orvosolható a probléma, ha nem engeded az átlapolódó y koordinátán lévő ablakokat ugyanazon az x koordinátán kezdődni vagy végződni, ahogy írod, csak ez bonyolítja az algoritmust, és így már annyira nem is egyszerű.

    Talán hátránya ennek a megoldásnak, hogy nem túl sok ablak esetén lassabb mint az 'analitikus' megoldás, viszont azt hiszem eszméletlenül sok ablak estén már lehet gyorsabb, mert ez lineáris sebességű, az meg n^2-es. Bár ilyen mennyiségű ablak nem reális. De végülis ez a része egyik algoritmusnak sem nagyon lassú az aktuális képernyőrajzoláshoz képest.

    A legfontosabb és legérdekesebb optimalizálási kérdés amúgy szerintem ez: milyen API-t biztosítasz az ablakokban futó programoknak, hogy rajzolják ki magukat? Ha az 'analitikus' megoldást választod, akkor az ablakozó rendszered oda tud passzolni egy clipping rectangle listát neki, hogy csak ezekbe rajzoljon. Ha nagyon igényesen van megírva a rajzolókódja az ablakokban futó alkalmazásoknak, akkor ettől ténylegesen gyorsabbak lesznek, (nem lineárisan a pixelek számával, mert bizonyos dolgokat valszeg mindenképpen meg kell tenni a paint kódban, de lehet sokkal gyorsabb.) Viszont a te módszereddel meg inkább vízszintes csíkok koordinátáit tudod átpasszolni neki, és talán egy átlagos paint kódot nem annyira könnyű úgy megírni, hogy ilyenből dolgozzon, és gyorsabb legyen. (De nem lehetetlen, pl. egy olyan algoritmusnál, ahol a pixelek kiszámítása tök független egymástól, mint a ray tracing, könnyedén működik a dolog; csak azokat a pixeleket számolja ki a paint kód, ahol van csík.)
    Mutasd a teljes hozzászólást!
  • Amit én gondoltam nem tetszik senkinek?
    Tudom hogy kicsit parasztész-megvalósítás, de a körvonalak rajzolgatásán kívül sok overhead nincs...
    Jó mondjuk be tud bukni, ha 1-1pixelre teszed egymástól az ablakokat pont határvonalra ugyanazon képernyőoszlopon, hogy ezt ne lehessen megtenni azt a szoftvernek kell biztosítania ez kicsit gány, de ez van...
    Mutasd a teljes hozzászólást!
  • majd egyenként megrajzolod őket, a legalsóval kezdve, egymás fölé, de úgy hogy csak azt a területet rajzolod amit az aktuális ablak elfed.


    Ez nem optimális megoldás, mert ha jól értem, itt ha 10 ablak van közel egymás felett, te mindet kirajzolod, kivéve, ami pont hátra ment. (Ha jól értem.) Én amúgy kb. ezt a részét oldottam meg a feladatnak (egy területet csak egyszer kelljen rajzolni), a többivel amit írtál nem is foglalkoztam, egyszerűen úgy tekintettem, hogy minden frameben teljesen újrarendereljük a képernyőt, de úgy, hogy egy területre csak egyszer rajzolunk. Ma már szvsz. a teljes képernyő kirajzolása megtehető. (A játék GUI-k pl. már mind így működnek.)

    Egyébként, ha belemész abba, hogy nem rajzolod újra a teljes képernyőt, az megtehető, de akkor bonyolultabb a dolog, mint amit én írtam. Egyrészt jön az amiket még hozzá leírtál, másrészt ez messze nem elég, mert az ablakok nem statikusak, képzeld el, hogy minden ablakod videólejátszó, (és olyan intelligensen van megírva, hogy a videót csak azokra a régiókra rajzolja, ahol megkérik rá.) Az én algoritmusom akkor is működik.

    Szóval amit írtam az egyáltalán nem varázslás, sőt talán az egyik legprimitívebb megközelítés azok közül, amelyek korrekten működnek dinamikus, változó tartalmú ablakok esetén is.
    Mutasd a teljes hozzászólást!
  • Nem kell ennyit varázsolni.

    Ablakkal alapvetően három dolgot lehet csinálni:
    1. Előtérbe hozás.
    2. Legfelső ablak elrejtése
    3. Mozgatás / átméretezés.

    Egy ablaknak pedig alapvetően 5 tulajdonsága van: x,y,szélesség, magasság és mélység (azaz hogy mi van mi fölött).

    1. Előtérbe hozás: Az adott ablak mélysége 0 lesz, az összes többi nő eggyel. Az adott ablakot megrajzoljuk (ettől ő eltakarja a többit).

    2. Elrejtés. Ez picit bonyolultabb. Először meghatározod hogy milyen ablakok vannak az aktuális ablak alatt, majd egyenként megrajzolod őket, a legalsóval kezdve, egymás fölé, de úgy hogy csak azt a területet rajzolod amit az aktuális ablak elfed. A legtöbb rajzoló API-ban van olyan amivel le lehet korlátozni a kirajzolható régiót.

    3. Mozgatás / átméretezés:
    A. elrejted az ablakot.
    B. Elmented a képernyôt egy bitmappe.
    C. Kirajzolod az ablakot.
    D. Ha méretezel / mozgatsz akkor úgy rejted el az ablakot hogy előszeded az elmetett bitmap aktuális részét, majd megváltoztatot az X, Y, W, H értékeket és C pont.

    Esetleg lehet duplabufferelni is.

    Szóval, szvsz nem nagy varázslat.
    Mutasd a teljes hozzászólást!
  • a teljesen eltakart téglalapokat megjelöljük, és mint takart téglalapokat már eleve nem vizsgáljuk


    Kicsit érthetetlenül írtam, szóval helyesen:

    a menet közben teljesen eltakart ablakokat (üres téglalaphalmazúakat) megjelöljük, és mint takart ablakokat már eleve nem vizsgáljuk őket, vagyis ilyenkor a potenciális takaróablakokra vonatkozó belső ciklusba bele sem kezdünk.
    Mutasd a teljes hozzászólást!
  • Kösz a segítségeket. (Már aki segített). Ha még tudtok segíteni, nyugodtan várom a hozászolásokat. Amúgy a 3d-re nem teljesen így gondoltam. Hanem, hogy mondjuk forgatható legyen az ikon, ilyesmi.
    Mutasd a teljes hozzászólást!
  • Kb. én is így csinálnám.

    Pontosabban így:

    Minden ablakhoz hozzá van rendelve egy téglalaphalmaz: ezek a területek kerülnek majd kirajzolásra az adott ablakból.

    Kezdetben legyen minden ablak halmazában egy elem, méghozzá az ablak területének megfelelő téglalap.

    Most egymásbaágyazott ciklus A,B-re a bottom to top sorbarendezett listán, ahogy te is írtad:

    A,B-re:
    A egyáltalán takarja egy kicsit is B-t? (Ez egy gyors csekkelés), ha igen, akkor jöhet a részletes vizsgálat: B téglalaphalmazából egy új halmazt állítunk elő a takarásnak megfelelően.

    Egy optimalizálás: a teljesen eltakart téglalapokat megjelöljük, és mint takart téglalapokat már eleve nem vizsgáljuk, vagyis a belső ciklus eltűnik egy csomó esetben.

    Szerintem normál mennyiségű és normálisan elhelyezett ablak esetén ez elenyésző ideig fut, nem biztos hogy érdemes nagyon belemenni ennek az továbboptimalizálásába.
    Mutasd a teljes hozzászólást!

  • Szerintem a boot szektor nagyon rá ér.
    Egy csomó dolgot kilehet fejleszteni futó OS alatt. (windows, DOS)

    Mutasd a teljes hozzászólást!
  • Sok jó assembler van. Nekem valamiért a nasm megtetszett.
    bochs nagyszerűen kiírja mitől szállt el a kicsi kis kernel kezdemény. Mert úgy is el fog, vagy 2000-3000 alkalommal biztos.
    Ha az MS virtualpc kiirja ugyanazt a dumpot akkor az is használható. Hasonlítsd össze a kettő kimenetét és meglátod a különbséget. Érdekes, hogy a bochs-ba még debuggert is építettek bele. Mondjuk én sosem próbáltam, de klassz lehet megállítani mondjuk a lapcsere kellős közepén és megnézni, hogy mi van éppen az eax-ban...
    Mutasd a teljes hozzászólást!
  • Lehet használni nyugodtan, normális assemblert,


    normalis assembler (jwasm)

    ui:
    A bochs-hoz kot valami?
    Probaltam de az MS virtualPC az hasznalhatobbnak tunt.
    Mutasd a teljes hozzászólást!
  • Hát lehet így is, de ez a fapados változat fapados változata. Nem értem miért kell olyan tanácsokat adnod amikkel tönkreteheti a saját rendszerét.
    Lehet használni nyugodtan, normális assemblert, ami tud bin formátumba dolgozni, pl. nasm. És akkor jön a bochs varázslat. Sokkal egyszerűbb, kultúráltabb stb.
    Mutasd a teljes hozzászólást!






  • Ami most van:

    Lista top-bottom sorrendben vannak az ablak pointrek letárolva.

    winlist 1,2,3,4,5,endlist

    (az 1-van legfelül)

    Van egy takart régió vermem.
    Hátulról megyek az ablak listán az utolsó előttivel, kezdem.
    Megnézem takarja-e az alatta lévőt.
    4-es-az 5-öst,
    3–as a 4-est és 5-öst.
    1->2,3,4,5

    Így kapok egy csomó érvénytelen területet.
    Ezeket kellene, még összevonom.
    A takart veremből, kiszámolok egy rajzolni vermet.
    Eseménykor a vermekből vágom ki azt amit ténylegesen kell frissíteni.





    Mutasd a teljes hozzászólást!
  • Ha tudsz COM-ot fodítani, akkor az a legegyszerűbb, ha megírod a COM programot(de ne használj DOS-os megszakításokat max BIOS-ost). Eztán nyomsz egy parancssort vagy totalcmd, vagy valami és odanavigálsz vele a COM-hoz aztán debug program.com
    A debug az tud írni szektorokat a lemezekre a w parancsot megadva(paraméterezéshez nézd meg a debug helpjét:?-el)
    A cím az a memóriacím, pl. egy egyszerű programot a 0100-tól kezdheted kiírni. a meghajtó az egy sorszám, a 0 az A: az 1 a B: stb(de ennek nézz utána!), a kezdő szektor szerintem magáért beszél, ha a nullást adod meg a floppy-nak akkor az a boot szektor lesz pont, ennek a tartalma beolvasódik a bios által bootoláskor és oda fog adódni a vezérlés a 0. bytera. A szám azt jelenti hogy mennyi byteot akarsz kiírni(vigyázz hexába van, mint a debugba minden).
    Ha 512 bytenál kisebb a progid, akkor elég kiírnod a bootszektorba az egészet cakkundpakk és benyomni a gépre majd rebootra már ott is van az ugráló zöld tehén, vagy amit csináltál... Ha nem ilyen kicsi, akkor mondjuk a bios lemezműveleteit használva(vagy saját IO hardveresen) kell beolvasni majd a többi részét és náhány másik szektort is feltölteni ugyanígy.
    Egyébként nem egészen normális telenyomni kóddal a bootsectort, mert ennek az elején egy jmp utasítás kéne legyen és a jmp meg a te kódod között egy ilyen leíró résznek hogy milyen fájlrendszer, milyen oprendszer, stb. Ennek guglizz utána, hogy hogyan is néz ki ez rendesen(mondom, megy enélkül is, de pl. nekem egy gagyi kis oprendszeremre pl. azt mondta a vírusírtó hogy boot vírus amikor benyomtam win alatt a lemezt, mondom na ez a megalol
    Mutasd a teljes hozzászólást!
  • Ne próbálkozz a hdd boot sector átírásával. Mert lészen sírás, fogak csikorgatása, és install CD behelyezése. Valamint kapkodás fájlok megmentése ügyében.

    Ha boot sector próbálkozásokat szeretnél elkövetni, javaslom a bochs emulátor letöltését. A linken található oldalon a Download Current segít ebben. Megfelelően telepített és konfigurált szoftver esetében lesz neked virtuális flopid. Na azon lehet próbálkozni.
    Mutasd a teljes hozzászólást!
  • "Ablak kitakarás, fedés régiók számolása, optimalizálása, ami nálam nem szépen van megoldva. (bár müködik nem publikálnám)
    Ha ehhez tudtok bármilyen infot az érdekel. (nem kell video)"


    Hát először valami sorbarendezős, heapes és hasonló dolgok jutottak eszembe, de egy kis idő papíron rajzolgatás után a következő találtam ki:

    -Azt csináljuk, hogy minden lehetséges ablakhoz hozzárendelünk egy színértéket(mondjuk [0..255]).
    -Kell egy színérték elemszámú tömb, tömb[x] az lesz, hogy az x.edik ablak milyen mélységben van. Itt ezeket a számokat karban kell tartani. Érdemes eleinte az értéktartomány közepe szerint vágni és oda rakni egy új ablakot, hogy tőle kissebbeket és nagyobbakat is könnyebben be lehessen szúrni. Ha ablaksorrendet változtatunk, akkor ebben a tömbben kell értékeket csereberélni...
    -Ezután kirajzoljuk a képernyőre az ablakok körvonálát a hozzá rendelt színnel.
    -A következő lépés a teljes képernyő sorfolytonos kirajzolása egy kicsit trükösen. Megnézzük hogy a jobb felső sarok fekete-e, ha igen akkor háttérkirajzoló állapotba lépünk, egyébként az ottlévő színhez tartozó ablak kirajzolásának állapotába. Haladunk tovább sorfolytonosan és állapotot váltunk, ha határvonalat érzékelünk. Azt tehát így mindíg tudni fogjuk, hogy az adott állapotban melyik ablakhoz tartozó területet kell rajzolnunk. Azt hogy az ablak területéről ide a képernyőre mit kell kirakni az pedig már könnyen kiszámolható az ablak koordinátáiból és a rajzolandó pont koordinátáiból.
    Az állapotváltások szintén könnyen kiszámolhatóak: Ha olyan nyitó borderhez érünk(bal oldala az ablakkereteknek), ami feljebb van mint a mostani állapothoz tartozó ablak mélysége, akkor arra az állapotra kell váltani, ha pedig a mostani állapot bezáró jobboldali pixele jön, akkor az eggyel korábbi állapotba állunk vissza. Ahhoz hogy a korábbi állapotra visszatérhessünk a vermet használjuk, ide lenyomjuk mindíg a korábbi állapot számát ha váltás van.
    -Természetesen nem kell mindíg az egész képernyőt újrarajzolni elég nyílvántartani, hogy az mi az a minimum és maximum x,y koordináta, amin belül megváltozik a képtartalom. Például ha egy ablak újrarajzolja magát akkor mindíg bejelenti a bal felső és jobb alsó sarkot. Ha pedig elmozgatjuk az ablakot akkor a bal felsőnek a mostani és a régi bal felső között a minimumot és a régi jobb alsó és a mostani közül a maximumot(ez azért kell, mert nem csak az új pozíciót kell újrarajzolni, hanem azt is ahonnan elmozdult az ablak).

    Nem próbáltam ezt ki, viszont félig papíron rajzolgatva, félig ide beírás közbe találtam ki, úgyhogy fogalmam sincs mennyire működik ez így. Elvileg a képernyőt a legrosszabb esetben is csak 2x kell átrajzolni az összes pixelen(és ehhez nagyon hülyén elhelyezett ablakok kellenek) és ha nincs túlzottan sok ablak, akkor a tömb számíinak a karbantartása se tarthat túl sokáig(és ezt is csak akkor kell csinálni ha a kijelölt ablak megváltozik egy másikra).
    Ja és nem tudom mennyire számít ez tudományosnak, viszont nem is érdekel. Ki kell próbálni és ha jól működik, akkor ki a fenét érdekel hogy tudományos vagy parasztész, nem?
    Mutasd a teljes hozzászólást!
  • Úgy nézzük.

    A felhasználó nem szakember. Az, hogy mit hisz, és igazából mi van a háttérben, nincs összefüggésben egymással. Neked a pcforum társalgójából DerX lenne jó dumapartner, el lennétek egymással jól.
    A többi zagyvaságot nem is kommentálom.
    Mutasd a teljes hozzászólást!
  • Hogyha floppival akarod kipróbálni akkor mi baja lenne a harddisknek?

    Egyszerűen ráírod a floppy bootsectorára és kész.
    Mutasd a teljes hozzászólást!
  • Figyusz, Senki!

    Érdekelne ez a boot-olós cucc, amit említettél! Még sohasem használtam, ebben teljesen kezdő vagyok. De az assembly-t már vagy másfél éve nyűvöm. Szóval egyszerű Dos-os com, exe meg win32-s progikat tudok írni.

    El tudnád magyarázni részletesebben?
    Ott azon a linken, amit ide feltettél van egy TASM-es kód. Nem sokat írnak róla, valami exe2bin-nel kell átalakítani, beírni a boot szertorba. De még azt se tudom, mire van a .bin formátum, és hogyan működik az exe2bin

    Először mindenképpen flopival szeretném kipróbálni. Van ennek egy olyan veszélye, hogy ha átírom a harddisk boot sectorát, nem fogom tudni visszaírni?

    Nem azt mondom, hogy én is egy 3d oprendszert akarok írni, de azért egy egész egyszerű kicsi progit ki szeretnék próbálni.
    Mutasd a teljes hozzászólást!
  • Már csak egy 3D proci kell hozzá és John Connor.
    Mutasd a teljes hozzászólást!
  • Ha így nézzük akkor "grafikus operációs rendszer" sincs.
    Amúgy ha egy oprendszer rögtön 3D-ben köszön be és nem is lehet ezt átállítani, szóval végig 3D a felület akkor a felhasználóban csak az marad meg, hogy ez az oprendszer 3D-s, hogy mi van a háttérben az nagyjából lényegtelen.

    Amúgy a memóriát is lehetne ábrázolni egy 3D mátrixként, és akkor a memóriát (egy eljárás címét) megadhatjuk a 3 koordinátával. A programok meg különbűző alakzatokat foglalnának a memóriában mint egy 3D tetris-ben. A feladatkezelő ki is rajzolná ezt 3D-ben. Ha meg indítunk egy programot akkor a program 3D "teste" fentről becsúszna a 3D-s memóriába, és ha elfér akkor fut, ha nem akkor jön a hibaüzenet, vagy az alsó sor "elporladna", a többi program lejebb csúszna és így helyet csinálna az új programnak.

    Erre mondhatjuk hogy butaság, de lehet 20 év múlva így fog ez menni.
    Mutasd a teljes hozzászólást!
  • Biztos hogy ezt nekem címezted ?

    Amúgy meg persze hogy nem. A 3D-s böngészők is itt haltak el egyebek mellett, mégy úgy 10 éve. Egyszerűbb rákattanni egy linkre mint átmenni egérrel egy másik szobába.

    Ezzel együtt néhány programban simán el tudnám képzelni a 3D-s felületet. Persze nem ügyvitelben, de Pl. 3D-s rajzolóprogramnál. Vagy olyan megoldásoknál amik ma még nincsenek is. Pl. egy rakodógépet sokkal jobban lehetne távirányítani egy VR kesztyűvel és sisakkal mint hogy Jakabka ott ül a kakasülőn 50 méterre a mozgatott tárgytól. De Pl. a kábelátvágásokat is meg lehetne előzni ha az árokásó gép is távirányítva van, és a dologra rá van vetítve a közműhálózat térképe. Plusz, esetleg a művelet térképe is. De ez nem oprendszer kérdése hanem programé.
    Mutasd a teljes hozzászólást!
  • Amúgy tök véletlenül most vettem, elő a saját os projectet.
    Cikket készülök írni, az ablak kezelésről.
    Persze rájöttem, hogy az én módszerem (ami működik) nem igazán tudományos.
    Ablak kitakarás, fedés régiók számolása, optimalizálása, ami nálam nem szépen van megoldva. (bár müködik nem publikálnám)
    Ha ehhez tudtok bármilyen infot az érdekel. (nem kell video)
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Szerintem olyan, hogy 3D op.rendszer, nincs.
    3D felhasználói interfész, az van.

    Érdekes volna, ha 3D vonatkozásokra kellene figyelni a lapozásnál, ütemezésnél vagy hasonló dolgoknál. Mielőtt 3D op.rendszerről szeretnél írni, előbb nézz utána a dolgoknak.
    Mutasd a teljes hozzászólást!
  • Hally!

    Én DJ_Hawkeye vagyok voltam és leszek is s progizni szertenék akarok tanulni mos egyépként a c++ logikályát tanulom megint és utána haverkodok megint c++ szavakal ijenekel ismerkedek hogy ..PL hogyan kel ablakot csinálni hogyan kel direct x-et csinálni hogy kel egy játékot csinálni hogy kel egy 3d-s modelt be tölteni

    Ja és senki nem fikuzza a mondat allkotási és hejes irási hibáimat mert én akk igen igy irok beszélek jól van na senki se tökéletes aszem ..

    Az angol nyelvel sehogy nem vagyok tisztába rakva mert németes vagyok de már odáig eljutottam hogy if meg else a célom egy jobb GTA össze rakása, hogyha lövök a fal össze omol meg ijenek tudom ez már az unreal engine a legújabb de nem kell ám pont hogy ojan legen csak egy modellt belerakom és kész.

    De lehet ám csak énis kamuból írok, hogy it szívasak mindenkit és jöt röhöglyek magamba!
    Mutasd a teljes hozzászólást!
  • Floppy meghajtó, az már tényleg unatkozik.
    Mutasd a teljes hozzászólást!
  • Amúgy szerintem a téma nyitója valamelyik unatkozó régi motoros lesz, annyira benne van az összes kezdőkkel kapcsolatos klisé


    CD ajtó?
    Mutasd a teljes hozzászólást!
  • ez a videó nagyon állat, végre mozogna egy kicsit a gerinc meló közben :)
    jól kivitelezve én tuti nem unnám meg egy darabig
    Mutasd a teljes hozzászólást!
abcd