- This topic has 22 hozzászólás, 4 résztvevő, and was last updated 21 years, 9 months telt el by
.
-
Bejegyzés
-
Hello!
A folyamatosan rajzolas azt jelenti, hogy nem egy filebol olvasom be az adatokat a pixmapre hanem a felhasznalo rajzolhat erre.De amikor ugye ezt fel szeretnem masolni az alap pixmapre mondjuk XCopyAreaval akkor az szepen ramasolja az alap pixmapre a cuccost.
attol fuggoen hogy a GC-ben milyen masolasi fuggveny van beallitva GXcopy,GXxor,stb, de sajnos egyik sem olyan ami ugye ekvivalens lenne a transparenttel 😥Sziasztok!
Tegnap nem talaltam jo peldat de most megvan:
tfh Van egy domborzati terkeped es erre szeretnel mondjuk turistavonalakat rajzolni interaktivan,azaz alapban megjelenik neked a domborzat arra pedig(mondjuk egy
rajzolo eszkoztar segitsegevel) vonalakat szeretnel rajzolni,ami ugye magaban foglalja a
modositas lehetoseget(mar megrajzolt vonalak torlese, athelyezese,stb)
Ha egy pixmappel(canvassal) dolgozol akkor magara a domborzatra rajzolod ra a vonalat (vagyis arra a pixmapre,canvasra) amin maga a domborzat van.Ez meg nem is gond,de ha mondjuk athelyezed a meglevo vonalat,akkor a valtoztatasok utan ujra kell rajzolnod a domborzatot es utana ra kell rajzolnod a gorbe megvaltozott helyzetet is.
Ha viszont ket pixmappel lehetne dolgozni akkor az athelyezes utan a domborzathoz nem kellene hozzanyulni,mert csak a vonalakat tartalmazo pixmapet kene felmasolni.
Valami ilyesmirol van szo.Most elvileg ket pixmap van, de amikor a domborzati terkepre felmasolom a turistavonalas pixmapet akkor csak a kovetkezo tipusus masolasokbol valaszthatok
src AND dst,src AND (NOT dst),src,(NOT src) AND dst,dst,stb
Ezek azt jelentik hogy egy adott pixel erteke mi lesz : az src == hogy az src pixmap pixelje lesz az eredmeny , a dst == hogy a dst pixmap pixelje lesz az eredmeny,src AND dst == hogy az eredmeny pixel az src es a dst pixel AND kombinacioja lesz (tehat a szin megvaltozik),stbDe nekem olyan kellene,hogy ahol az src erteke a hatterszin ott a dst legyen ekllenkezo esetben viszont src legyen.Es itt lenne jo ha pl a felso pixmapen a hatterszin helyett „atlatszo” pixelek lennenek.
Egyebkent a kornyezet amiben ezt az egeszet meg kellene oldani Motif, illetve az Xlib fuggvenyek .
Szoval ez a palya,remelem most mar ertheto a problema.Es koszi ,hogy probaltok segiteniHello
Koszi a megjegyzeseket.Nem, egyaltalan nem akarom megeroszakolni az XLib-et 😀
A helyzet az, hogy az egesz rendszer XLib fvekkel van megirva,ezert probaltam meg ilyen iranyban probalkozni,de egyaltalan nem zarkozom el mas, magasabb szintu technikaktol.A teljes rendszerhez nem lehet (nem is nem lehet, hanem mar nem lenne kifizetodo) hasznalni mas grafikat(maradunk az XLibnel) de ezt a problemat me’g meg kellene oldani es ehhez igenybe vennem az altalad felvazolt 2d-s technikak egyiket..
Ehhez viszont abban a tekintetben kernem a segitsegedet, hogy melyek azok a konyvtarak amiik segitsegevel ezek,pl a retegkezeles (szamomra ez lenne a legjobb) megvalosithato?
KoszHmm, tehát van egy „hõskorból” származó forráskódod, amit módosítani vagy újra megvalósítani szeretnél.
Informatikai léptékkel réges-régen, még a PCI busz elõtt, a nagy Hõskorban a számítógépek teljesítménye miatt nagyon sok terület erõsen korlátozott volt. A számítógépes grafika egy tipikus I/O korlátozott terület volt, hasonlóan az elosztott rendszerek párhutamos feldolgozásához. Nevezetesen a grafikus kártya csatolófelületének sebessége nagyságrendekkel lassabb volt, mint a grafikus processzor és a kártyán levõ memória sebessége. Azért aztán a grafikus algoritmusokat is ennek megfelelõen kellett megtervezni. Az ebbõl az idõbõl származó egyik leghatékonyabb és legelterjedt megoldás neve: X Window System.
Az Xlib-bõl hiányoznak az olyan funkciók, amiket abban az idõben a grafikus processzor nem tudott végrehajtani, mivel a grafikus mûveleteket a CPU a lassú csatoló miatt nem dolgozhatott fel. Jelenleg egy ablakos renderelési módszert használnak általában, ahol csak a látható részek kerûlnek kiszámításra, és az adatok tömörítve vannak a memóriában, vagy valós idõben értékelõdnek ki.
http://www.cab.u-szeged.hu/local/linux/mot…tif/node16.html
Ehhez viszont abban a tekintetben kernem a segitsegedet, hogy melyek azok a konyvtarak amiik segitsegevel ezek,pl a retegkezeles (szamomra ez lenne a legjobb) megvalosithato?
Nagyon sok létezik, de nem biztos, hogy szükséged van rá. Szerintem a legtöbb esetben elég pár alapalgoritmus, amiket a már meglevõ adatstruktúrához lehet igazítani.
Pár hasonló GPL-es megvalósítás:
http://www.gpsdrive.de
http://phpwirelessmap.sourceforge.net
http://gpsmaps.org/vikingHali!
Koszi szepen,akkor megprobalok ebben az iranyban keresgelni.Gondolom,hogy csak par fvre,algoritmusra van csak szuksegem,remelem sikerul megtalalni a megfelelot.
Viszont akkor mar megkerdeznek meg valamit,talan ebben is tudsz segiteni.
Ha mar eddig a turistavonalaknal tartottunk akkor maradjunk is ott 😀
szoval arra lenne szukseg hogy az a franya turistautvonal rendes,szep gorbe legyen es ne egy szakaszokbol allo vonal torespontokkal 😀
Magyaran egy olyan algoritmusra lenne szuksegem ami adott pontokra fektet egy gorbet.A lenyeg hogy a gorbe menjen at a kijelolt pontokon.
Vagy (hu de kenyelmes leszek:D ) nincsen olyan konyvttar aminek segitsegevel ez konnyen megvalosithato lenne?Magyaran egy olyan algoritmusra lenne szuksegem ami adott pontokra fektet egy gorbet.A lenyeg hogy a gorbe menjen at a kijelolt pontokon.
Ezt interpolációnak hívják, de már említettem. Sokfajta létezik, mindegyiknek van elõnye, és hátránya. Talán a leghatékonyabb ebben az esetben a sok vezérlõpontos koszinusz-interpoláció.
http://astronomy.swin.edu.au/~pbourke/anal…/interpolation/Vagy (hu de kenyelmes leszek:D ) nincsen olyan konyvttar aminek segitsegevel ez konnyen megvalosithato lenne?
Biztosan van 2D-s is, de a legtöbb 3D-s, amit át lehe alakítani (Z=0).
http://public.kitware.com/VTK/
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz