Sziasztok. Bár több kisebb progit írogattam már C/C++ -ban, de most lenne az első, amihez grafikus felületet is mesterkednék. Ez nem egyszerű nekem, mert még nem találtam erről részletes magyar leírást.
Tehát, egy nagyon egyszerű(nek tűnő...) progi kéne, amit váznak használnék, mintegy kiindulásnak. A következőt kéne tudnia:
Elindítom, erre megjelenít rögvest egy ablakot, lehetőleg fullscreenben rögtön, ha ez nem lehet akkor valami fixen beírt x-y méretűt (pixelben értve). Az ablak azt tudja, hogy átméretezhető legyen, maximalizálható és bezárható. (Tálcára tevéssel nem kell foglalkozni). Az ablak fejlécére megadható legyen valami szöveg.
A progi ha véget ér, magától zárja be az ablakot.
A progiban kéne egy "kiir" rutin (na ez a legfontosabb...) ami annyit tesz hogy ha meghívják (program indulásakor természetesen meg kell hívni) akkor megtölti "tartalommal" az ablakot. Ez úgy menne hogy van egy
unsigned char *M;
tömb, (tudom, ez csak a mutatója...) és ebben egymás után bájt-tripletek vannak, amik sorra R,G,B színösszetevőket tartalmaznak. Ez az M tömb úgy értelmezendő, mint egy 1024×768-as pontmátrix, mindegyik ponthoz egy ilyen r-g-b triplet tartozik. No és a "kiir" rutin csak annyit tenne, hogy ezen M tömbből kirajzol annyi ilyen pontot a megfelelő színnel az ablakba, amennyi abba belefér. (Tehát az M tömb "balfelső negyedét" rajzolja ki mindig az ablakba, annyit, amennyi odafér, mintha egy TrueColor kép lenne). Ha az ablakot átméretezi a felhasználó, természetesen nő vagy csökken a megmutatott terület nagysága.
Kéne még egy "beolvas" függvény is, ami mindig meghívódna ha valami billentyűt lenyom a kedves felhasználó, s ennek kódját valami változóban e függvény felhasználhatná. Egérkezelés egyelőre hanyagolható. (Tulajdonképpen az ablak átméretezése is ha nagyon bonyolult, feltéve hogy fullscreen-ben tud indulni).
Ehhez már csak annyi kéne, hogy a "kiir" rutint be lehessen állítani úgy, hogy magától rendszeresen végrehajtódjon, másodpercenként Y alkalommal. Y valami extern változó lenne, célszerűen char típusú, mert biztos hogy Y<100 azaz beleférne.
Maga a tulajdonképpeni program e kiegészítő rutinokhoz csak annyiból kell álljon, hogy
int ezabelseje(void) {;}
hogy tudjam, hogy ide kell elhelyeznem a fő dolgokat amik a program lényegét alkotják majd.
Volna valaki olyan kedves hogy ezt megírja nekem, hadd tanuljak belőle, vagy ez túl nagy kérés?
Ó igen, és az is okvetlenül kéne, hogy milyen pontos paranccsal fordítsam le ennek a forrását, mert gondolom kell majd hozzá valami olyan lib hogy GTK, Qt vagy akármi, bár örvendenék ha minél kevesebb függősége volna...
Előre is köszi!
Hozzászólások
Szóval valaki tanítson meg GUI-t programozni! :-{)E
Letölthető Pere László a GNU/Linux grafikus programozásáról szóló, új könyve
De ha GUI-t akarsz és nem ragaszkodsz a C/C++-hoz akkor: http://learnpython.openproject.hu/ vagy kicsit átdolgozva de lényegében ugyanaz: http://python.free-h.net/
Köszönet érte ez úton is Daróczy Péternek.
Nagyszerű, köszi szépen, már le is töltöttem!
Ettől függetlenül nem haragudnék meg, ha valaki megcsinálná a kért példát nekem... rengeteget tanulhatnék belőle.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Hasznos lehet még ez is: http://gtk.pergamen.hu/
Köszi, ezt is letöltöttem!
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Igen, pont arról van szó, hogy valaki tanítson meg egy példaprogi által GUI-t programozni. De nem vagyok talán nagyigényű, mert tényleg csak a példaprogit kérem, ami talán elég egyszerű, pld nem kértem olyasmit, hogy TrueType fontok kiírása az ablakba, meg a teljes egérkezelést kihagytam...
Viszont a C/C++-hoz kénytelen vagyok ragaszkodni. Nincs rá időm, hogy megtanuljak egy másik programnyelvet is. Épp elég nagy feladat lesz mostani időhiányos állapotomban a GUI programozása a megszokott C nyelven is nekem.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
LOL
Errol ezek jutnak eszembe:
[1/6] php.hu [18:07:48] akkor ez a csati minek van, ha nem support? manualt bongeszni en is tudok, de mos gyorsan kellene megoldas, hogy tovabb tudjak lepni
[2/6] php.hu [12:16:18] mi a fasze vagytok ezen a csatin ha nem segiteni
[3/6] php.hu [16:00:03] asszem fosok az egészre és megcsinalom flashbe
[4/6] php.hu ... azert mert nem vagyok jartas phpban, meg ember vagyok..
[5/6] php.hu (xxxxx) es hogy csinalok key-es tombot? :)
------------------
- The Question is: What is mahna mahna?!
- No! The question is: Who Cares!
Türelmetlen az ifjú, de nem kell ezeket felhánytorgatni! Úgy ő is hamarabb elfelejti, megváltoztatja ezt a fajta viselkedést.
Nem arról van szó, hogy türelmetlen vagyok, hanem ha egyszer már aránylag jó ismereteim vannak C nyelvből, miért is ne ezt mélyítsem el a GUI felé, minek kezdjek egy tökismeretlen másik nyelv magtanulásába, amikor úgy biztos tovább tart! Továbbá, természetesen nekem is mint mindenkinek megvan a magam (bevált) tanulási módszere. Példaprogramon át nekem könnyebb. Ettől természetesen még áttanulmányozom a dejo által belinkelt szakirodalmat is. Az nyilvánvalóan muszáj, mert ha valaki meg is írja a kért progit, az tényleg nagyon alap, arra nekem még egy rakás minden kell, amit mégiscsak én leszek muszáj megírni. Mindössze lenne egy kiindulási pontom.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Nem az a gaz amit kersz hanem ahogy kered, de nekem tok mind1, megertem amirol beszelsz, csak nem kellene imho defaultkent elvarni hogy valaki ezt meg fogja irni neked. De ezt majd eldonti aki megirja vagy nem irja meg.
------------------
- The Question is: What is mahna mahna?!
- No! The question is: Who Cares!
Én viszont nem értem, hogy TE miről beszélsz. Szerintem tök normális a bejegyzésem. Leírtam, hogy e téma programozásával még nem foglalkoztam, és szerintem egy egyszerű kis progi ami a leírt kritériumoknak megfelel, sokat lendítene a tudásomon, és talán akad valaki aki lesz olyan kedves hogy megírja nekem. Mi ebben a gond? Nem követelőztem, nem használtam csúnya szavakat! Ha valaki megírja, örülni fogok neki. Ha senki nem írja meg, akkor nem történt semmi különös, nem lettem szegényebb, csak lett egy újabb kihalt topik a sok HUP-topik közt a fórumban.
Különben, nem hinném hogy valami rém nagy feladat volna annak, aki amúgy rendszeresen szokott GUI-t programozni. NEKEM persze nagy feladat, mert még tökhülye vagyok hozzá. Épp ezért lenne ez azonban nagy segítség! Nem, én egyáltalán nem tartom lehetetlennek, hogy valaki megírja, mert én szívesen hiszek abban, hogy az emberek - néhány kivételtől eltekintve - alapvetően jók! Aztán lehet hogy csalódni fogok, de ez ahogy mondani szokás "benne van a pakliban".
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Ha ragaszkodsz a C++-hoz, akkor a QT-t ajánlom.
Általában pedig elmondható, hogy garfikus programozás mint olyan, egész tág fogalom. Mert ugye van sima Xlib, amit használhatsz. Aztán vannak a különböző widgetset-ek, amikkel egy kicsit egyszerűbb az élet, mint egy sima Xlib-bel. Szóval a kérdés csak az, hogy milyen widgetset-et fogsz választani. Ettől még írhatod a progidat c++-ban, csak a set támogassa a dolgot.
Másrészt ajánlanám azt, hogy mivel nyílt forrású programokkal foglalkozunk itten (többnyire), talán letölthetnél valamit és belenézhetnél. De itt is el kell határoznod, hogy gtk, qt, xlib, Tk, stb.
http://linuxgazette.net/issue78/tougher.html --Xlib programming in C++
Nem, pontosan Te latod rosszul. Ha most nem tanulsz meg referencia alapjan tanulni (nem felreiras: tanulj meg tanulni!), akkor az az eletbe nem fog menni. En is ilyen voltam, es neha ilyen vagyok ma is. De kenyszeritem magamat, hogy olvassam at a referenciat, es probaljak magam alkotni, mintsem hogy konyorogjek barkinek is. Az alatt az ido alatt, amig itt konyorogsz, korulbelul 5-6 peldat mar reg ki lehetett volna probalni. Gondolkozz el ezeken...
Az első dolog amit meg kéne álmodni, hogy C vagy C++.
Mert ez két különböző nyelv, más-más gondolkodásmódot igényelnek, stb.
Abból, hogy összemosod a kettőt arra gondolok, hogy eddig C-ben programoztál. :)
Tehát ha C, és relatíve könnyen akarsz ablakozni, akkor szerintem GTK.
Egy rakás tutorial van a neten példákkal, mások biztos tudnak neked ajánlani. (Én nem Gtk-zom.)
Ha C++, akkor rögtön több lehetőséged is van: Gtkmm, Qt, wxWidgets.
Mindegyikhez remek tutoriálok vannak a neten, illetve a hivatalos honlapon, és rengeteg példaprogram.
Viszont mindegyik feltételez egy biztos C++ tudást, anélkül rohadt nehéz lesz...
(Én használtam mindhármat, a wxWidgets régivágású úriember, alig használja ki a C++ lehetőségeit, így talán kisebb C++ tudással egyszerűbb, viszont nem is olyan elegáns.
A Gtkmm elég letisztult, kényelmes, és Gtk :), viszont alap GUI-n és filekezelésen kívül alig lehet benne mást csinálni.
A Qt letisztult, modern, rengeteg minden van benne, de talán nem a legegyszerűbb.)
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Ezen nem kell gondolkodni! C++
QT-Tutorial. Részletesen elmondja egy néhány példaprogramon keresztül még az IDE kezelését is.
--
unix -- több, mint kód. filozófia.
Life is feudal
Már hogy a francba ne kéne ezen gondolkodni?!
Én még emlékszem mekkora kínszenvedés volt az első C++ programom megírása... 5 sor programban volt 10 hiba. :)
Ez az erősen típusosság az őrületbe kergeti az embert különösen ha C-t használt addig.
Egyszerre váltani C-ről C++-ra, és elkezdeni GUI-t programozni felér egy öngyilkossággal.
Persze van aki így kezdi, és össze is rak egy egyszerűbb programot, csak nem fogja érteni miért működik, mi történik a háttérben, és, hogy mikor kell felszabadítani valamit, illetve mikor hagyhatja a rendszerre (pl Qt). A program garantáltan tele lesz memory leakekkel, és a következő komolyabb programban már megoldhatatlannak tűnő problémák jönnek...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
"nem fogja érteni"
Mi vagy te? Látnok? Lottószámokat nem tudod?
--
unix -- több, mint kód. filozófia.
Life is feudal
De tudom. Szerinted ki nyerte a legutóbbi ötöst? :)
Egyébként tapasztalat. Nem egy embernek segítettem itt a fórumon is, akiről kiderült, hogy nem érti a Qt memóriakezelését, stb. mert alapvető C++-os dolgokkal nincs tisztában.
Nehéz úgy falakat emelni, ha közben kell alapozni...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Én sem értem a Qt memória kezelését vagy hogy mikor kell valamit felszabadítani :), de nem is vagyok szerencsére főállású programozó. C-t nem sokat tanultam, C++ meg Qt egyenest és ott a nagy Qt könyvben nem sokat foglalkoznak ilyen kérdéssel, hogy felszabadítani valamit.
Rendszeresen monitorozom a Qt programok memória és cpu igényét, eddig orbitális memória szivárgást mondjuk nem láttam, de nem szeretnék hülyén meghalni :) van valami jó összefoglaló iromány amit ismersz, az ilyen programozói hibák elkerülése érdekében? A kérdés komoly....
miert foglalkoznanak vele? alap c++. ha nem ismersz ilyet, ne kezdj el qtzni :)
amugy letezik olyan, hogy C++ hibaelharito, kiskapunal pl. vagy C++ csapdak? ilyesmi :-)
Azt értem, hogy nem tanítanak C++ programozást a Qt könyvben, de a példa programokban se sok mindent láttam, ami ilyesmit csinálna. Pedig rengeteg példa kód van... Szóval nem igazán tudtam eldönteni sose, hogy (1) én vagyok hülye hozzá (2) ne parázzak, ha jól működik.
A dolog egyébként nem túl bonyolult.
Normális esetben C++-ban ha new-val foglalsz területet valaminek, akkor illik azt delete-tel felszabadítani. (Hasonlóan C-ben malloc/free)
Viszont ha megnézel egy Qt-s példaprogit azt látod, hogy pl az ablak konstruktora tele van new-kkal, de delete a programban egy szál se.
A trükk az, hogy Qt-ben minden widget QObject leszármazott.
A konstruktorban ugye létrehozzuk az alwidgeteket new-val, és mindegyik konstruktorának átadjuk a szülő widgetet. Ami elsőre nem világos, hogy ez a szülő átadás nem csak azért fontos, hogy ne külön ablakban jelenjen meg, hanem abban a widgetben amiben mi szeretnénk, hanem azért is, mert a QObject olyan, hogy megadhatunk neki szülőt, illetve neki is lehetnek gyerekei (akik őt nevezték meg szülőnek).
Ha egy QObject destruktora lefut, az felszabadítja a gyerekeit is.
Tehát ha törölsz egy widgetet, akkor az felszabadítja az alwidgetjeit is, sőt, szól a szülőnek (ha van), hogy ő már megszűnt (ezért nem lesz többszörös felszabadítás).
Ezzel kb elmondtam, hogy miért elég egy delete. Nade általában Qt-ban nincs delete egyáltalán!
Azért mert általában a fő ablakot a mainben hozzuk létre közvetlenül a QApplication után mint lokális változót, tehát nem new-val.
Tehát amint kilépünk a blokkból, a lokális változó megszűnik, azaz a destruktora lefut, és felszabadít mindent amit kell neki.
A lényeg, hogy ez mindenre így működik ami QObject.
Ami nem, ott vagy nekünk kell kézzel, vagy említi a leírás.
Remélem érthető voltam, mert rohadt fáradt vagyok. :)
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Köszi tr3w, világos. Nagyjából én is úgy okoskodtam, hogy amíg a QObject örököseiről meg gyermekeiről van szó, addig sokat nem kell félnem. :) Nem egyszerű C++-ban jól programozni. Sajnos suliba C volt csak, abból is kevés, OOP-ből ki sem mondom mit tanultunk, mert azt hinné mindenki, hogy csak kitaláltam azt a nyelvet, nincs is olyan :P Majd beküldöm egyszer a humor rovatba. Úgyhogy mindent könyvből/webről csipegettem fel, néha jó volna egy "mentor" akivel megvitatom a dolgokat, dehát itt vidéken még linux használóval is ritkán találkozom, nemhogy olyannal, aki C++ zseni :)))
Programozást amúgy sem nagyon lehet oktatni, legjobban a saját hibáiból és küszködéséből tanul az ember. A lényeg az, hogy igényes legyen, és akarjon szép kódot írni, és ne legyen lusta átírni egy fél programot csak azért mert rájött, hogy úgy "szebb".
Könyvből meg (ha még nincs meg) szerezd be Stroustrup-tól A C++ programozási nyelv-et. (Tudom, drága...)
Persze nem a legizgalmasabb olvasmány, főleg ha már egy kicsit ismered a C++-t, mégis olyan fejezeteken is érdemes átrágni magad, ami olyan dolgokról szól amiről azt hiszed érted. Rengeteg jó ötlet van benne, és rávilágít az összefüggésekre.
A C++ "atyja" írta, és nem csak azt írja le benne, hogy mi hogyan működik, hanem azt is, hogy miért pont úgy. Ettől sokkal érthetőbb lesz minden.
Még a Hatékony C++-t (Scott Meyers) szokták ajánlani, ez nekem még nincs meg. De ezt már csak 2. könyvnek.
Egyébként itt a fórumon nyugodtan kérdezgethetsz C++ témában, vagyunk egy páran akik azt képzeljük magunkról, hogy értünk hozzá. :)
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Szoktam fél programokat átírni :)
Mivel más programozási nyelvekkel foglalkozgattam, én gyakorlatilag a http://www.cplusplus.com/doc/tutorial/ oldalról tanultam meg :( :) Nekem bejött.
A könyveknek utánna fogok nézni, jól jön a tanács, mert sajnos a szakirodalomból is már annyi van, hogy nehéz ránézésre megmondani mi lesz hasznos. Van aki csak pénzt akar vele, vagy kötelező jegyzetnek lenyomja... aztán úgy kezdődik, hogy a main(..) void típus :(
Ha gondom lesz kérdezni fogok :) Igaz, olyan nagy gondjaim nincsenek, inkább amolyan "best practice" jellegű dogok hiányoznak a tudástáramból, amikor hasonló megoldásokból nem tudom mi alapján kiválasztani, hogy mi lenne a legjobb és legszebb megoldás. Az első könyv lehet hogy sok ilyesmire fényt derítene, úgyhogy mindenképpen utánna nézek. Köszönöm.
A Stroustrup az alapoknál kezdi, de szerintem ebből nem lehet 0-ról más nyelvek ismerete nélkül megtanulni C++-ban programozni. Mondjuk első nyelvnek nem is ajánlanám. :)
A Hatékony C++ címe ne tévesszen meg, itt a hatékonyság nem a programra, hanem a fejlesztésre vonatkozik, "50 jó tanács" van benne, azaz 50 gyakori/érdekes probléma szép illetve csúnya megoldása.
Elvileg pont a neked kellő "best practice", de ezt tényleg haladóknak/profiknak ajánlják. Ezt ítéld meg magad. :)
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
A Stroustrup-féle két kötetes C++ könyv és a "Hatékony C++" valóban alapművek, és hasznos még a "C++ hibaelhárító" is. Sőt, én még ajánlom a Fowler-féle "Refactoring a gyakorlatban" könyvet is, ami bár Java kódot tartalmaz (asszem), rengeteg hasznos ismeretet szerezhet belőle az ember arról, miért rossz a kód amit írt (az is hiba, ha a program áttekinthetetlen!).
(Szerk.: átfogalmazva)
Sőt, van olyan, hogy
Andrei Alexandrescu, Herb Sutter: C++ kódolási szabályok
bár szvsz a Hatékony C++ sokkal jobb.
Ha jol tudom, neked nem sokat kell a (Qt-s dolgok) memoriafelszabaditasaval foglalkoznod, azt a Qt main loopja elvegzi, amikor a szulo widget torlodik. Persze az alapvetoen dinamikusan altalad lefoglalt teruleteket neked kell eltakaritanod.
Szerk: nem a main looprol van szo, hanem arrol, hogy ha egy widget bezarodik/torlodik/etc, tehat meghivodik a destruktora, akkor automatikusan az o gyerekeinek is meghivodik a destruktora.
/Nem, nem magammal vitatkozok, de ez van ha egy hupper leul a gep ele.. Rogton azt hiszi, hogy o van bejelentkezve.. :)/
Azért az az erős típusosság elég relatív. Egy csomó olyat megenged, amelyet egy valóban erősen típusos nyelvnek nem kéne. A C meg a vicc kategória e téren.
Cegnel van egy rakat structunk 1 szem unsigned int el benne :) A tobbit kitalalod... De tok igaz a C nem arra valo, hogy tipus eros legyen.
==
`Have some wine,' the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.
Szerintem először pontosítsd légy szíves, hogy mit is szeretnél csinálni, ugyanis van több lehetőség, de mindegyik másra jó:
- A GTK leginkább ott hasznos, ha ablak-elemekből (pl. gombok, csúszkák, lenyíló kiválasztó-ablakok, stb.) szeretnél egy grafikus felületet csinálni. Természetesen ebben is van olyan ablak-elem (widget), amiben nyers képadatot lehet megjeleníteni (GtkImage típus), de alapvetően nem erre van kihegyezve, így erre van nála gyorsabb megoldás is.
- Az SDL főképp egyszerűbb játékok készítéséhez jó, ő annyit tud, hogy egy ablak teljes megjelenített területét pixelenként el tudod érni, és ráadásul elég gyorsan (plusz hangkártyát, botkormányt, stb. is). Viszont fogalma sincs olyasmikről, hogy ablakelemek és hasonló újmódi huncutságok :)...
- Az OpenGL szintén nem beviteli felületekhez való, viszont komplett 3D testeket tud megjeleníteni, és ebben a videokártyád képességeit is (többé-kevésbé...) igénybe veszi, így sokkal gyorsabb, mintha te magad számoltatnád le ugyanazt a procival.
Bármelyikhez keríthetünk példaprogit, csak az a kérdés, hogy melyik legyen? Konkrétan:
- ha csak pixelesen rajzolni szeretnél, akkor SDL
- ha viszont (akár később is) kell user beavatkozó felület (gomb, szövegmező, stb.) is, akkor GTK
Egyelőre nekem pontosan annyi igényem van csak a GUI-t illetően, mint amit a nyitó "beszédemben" leírtam. És programoztam már C++-ban. Azért írom úgy, hogy C/C++, mert szeretem akkor is a C++ fordítót meghívni ha amúgy nemigen használom a C++ specialis lehetőségeit, mert valójában C-ben programozom, s nincs egy szál osztály sem a progiban, csak nagyon kevés C++ jelölésmód, pld nem kell mindenhol teleszemetelnem a progimat "struct" szócskákkal, meg használom azt, hogy függvényeknek vannak alapértelmezett paraméterei... tehát: kell egy ablak, amibe periodikusan kirajzolom egy memóriaterület tartalmát, a tartalmat TrueColor pixelenként értelmezve. És persze kell valami interfész amin át kommunikál a felhasználóval, azaz kell fogadja a billentyűleütéseket. Nagyjából ennyi. Nem kell nekem egyelőre 3D meg bámi csicsa.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Azt hiszem a sima X programozása (xlib) lesz a jó nekem! Annak tényleg nem sok függősége van, és miután _valóban_ csak annyi kéne nekem egyelőre mint amit leírtam (egy memóriaterület TrueColor pixelenként való kirajzolása), emiatt nincs is szükségem mindenféle GTK vagy Qt csicsára. S így talán nem veszek el annyira a sok szolgáltatás bonyolultságában.
Van-e valami jó magyar nyelvű leírás az X programozásáról? Mert leírást találtam, de csak angolul...
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Ne tedd, nem éri meg a szenvedést. Inkább javaslom az SDL-t, az is kb. onnan indulhatott, hogy valaki nekilátott egy ember számára is használható rutingyűjteményt írni az xlib fölé.
Alant írtam egy kis példaprogit, ami true-colour pixelkirakást csinál, bár az általad említetthez képest van pár eltérés:
- nem 3 byte/pixel, hanem 4, azaz 32 bpp
- nem egy memóriaterületet _másol_ ki a képernyőre, hanem elkér egy címet, ahová írhatsz, majd azt robbantja ki a képernyőre
- ez a terület a videokártya memóriájában foglalódik (ha jól vettem ki a leírásból), ezért aztán (gondolom bitblt-vel) némiképp gyorsabban rakódik ki, mint egy sima mem->mem blokkmozgatásnál
Kell hozzá a 'libsdl1.2-dev' nevű csomag, fordulni pedig így fordul:
gcc -o proba -O3 -Wall -lSDL -lm proba.c
Hű aztamindenit, még működik is! Mármint úgy értem, nem volt nálam SDL telepítve, de felraktam, és le is fordult, bár csak g++ -al a gcc helyett. Ha gcc-vel akartam fordítani, ezt írta ki amiről fogalmam sincs mit jelent:
vz@Csiszilla ~/xlib-programming]gcc -o proba -O3 -Wall -lSDL -lm os.cpp
os.cpp: In function 'int main(int, char**)':
os.cpp:66: warning: converting to 'int' from 'double'
os.cpp:67: warning: converting to 'int' from 'double'
os.cpp:71: warning: converting to 'int' from 'double'
os.cpp:72: warning: converting to 'int' from 'double'
os.cpp:76: warning: converting to 'int' from 'double'
os.cpp:77: warning: converting to 'int' from 'double'
/System/Variable/tmp/ccKm1kti.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
Itt természetesen az "undefined reference"-re gondolok hogy nem tudom miért írja ki - a többi világos.
Na de g++ -al lefordult.
Nagyon szépen köszönöm, kedves gsimon, hát akkor ezt most alaposan át kell tanulmányoznom, megváltoztatni, meg egyéb mindenfélék. Pld, a következőket kell mindenképp megvariálni:
1. Rájönni, miként tesztelhetem le, milyen billentyűt nyomott le a kedves user. Mondjuk, lehet hogy ezt az SDL_KEYDOWN tartalmazza, még nem néztem bele.
2. A görberajzolós részt kicserélni arra, ami nálam tölti fel adatokkal a memóriaterületet.
3. beállítani, hogy másodpercenként Y-szor rajzolja ki az egész memóriaterületet - biztos van valami C vagy C++ függvény, ami ilyesmit csinál, hogy egy rutint ráköt a megszakításrendszerre, ennek utána kell néznem a könyvekben.
4. Más apróságok
Azt hadd kérdezzem meg azért, miért 4 bájtos részekből áll a memóriaterület? Úgy vettem észre a negyedik (nulladik...) bájt mindig 0. Ennek csak az az értelme, hogy a 4, az a 2 hatványa s így valami gyorsul valamelyest?
Mindenesetre rengeteget segítettél, de tényleg és igazán, le a kalappal előtted!
Tulajdonképpen merő pofátlanság lenne újabb kérésekkel előhozakodnom, így már csak annyira merészkedem hogy megkérjelek, ha NETÁN tudsz valami magyar nyelvű leírásról ezt az SDL-t illetően, akkor kérlek lökd ide a linkjét neki! Meg találtam valami olyasmit hogy ksdl, ez most mi, mennyiben másabb mint az sdl amit felraktam? Csak amiatt kérdem, mert ehhez mintha lenne magyar leírás, csak nem tudom az ottani infók mennyiben azonosak azzal, amit én tudok használni a mostani rendszeremben.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
1., Lenyomott billentyű
A kulcsszó az SDL_PollEvent() által beállított 'SDL_Event event'. Ennek -ha a típusa SDL_KEYDOWN- van egy 'key' nevű mezeje, ami a billentyű-eseményről mond információkat, többek között egy 'keysym' nevű mezőben a lenyomott billentyűről, aminek van egy 'sym' mezeje a bill.kódnak ill. egy 'mod' a módosító billentyűknek (shift, stb.).
Azaz:
Az 'event.key.keysym.sym' a lenyomott billentyű ascii kódja (ha van neki olyanja), ill. előre definiált konstansok a speciális billentyűknek, amik a /usr/include/SDL/SDL_keysym.h-ban vannak felsorolva.
Az 'event.key.keysym.mod' egy bitekből összerakott szám, ahol az egyes bitek az egyes módosító billentyűk állapotát jelzik, pl. a 0x1000 bitje (KMOD_NUM) a numlock bekapcsoltságát mutatja.
Érdemes az egyes függvények man-oldalait végigböngészni, esetleg az ott a 'See also'-nál sorolt egyebekét is, végső esetben pedig az összes definíciónak ott kell lennie valahol a /usr/include/SDL/-ben - nem doksi, de pl. konstansokat ill. struktúrák felépítését ki lehet belőle bogozni.
2., Rajta :) !
3., Van rá mód, az SDL íróinak is volt ilyenre szükségük :)
4., A 32 bites pixel-ábrázolás okát jól látod, tényleg az elérési sebesség van a dolog mögött, ui. elektronikailag is könnyebb 4-gyel szorozni (2 bittel arrébb drótozod és kész), mint 3-mal, így maga a videokártya is gyorsabban tudja kezelni, de te is gyorsabban címzed, ui. ha pl. 1024 pixeled van egy sorban, akkor a j. sor i. pixelének a byte-címe 24 bit-per-pixel esetén: 'offs = 3*(j*1024 + i)', amit max. odáig lehet optimalizálni, hogy 'k = (j << 10) + i; offs = k+k+k;'.
Ugyanez 32 bit-per-pixel esetén: 'offs = 4*(j*1024 + i) = ((j << 10) + i) << 2'
Esetenként amúgy jól tud még jönni az a plusz byte pixelenként, pl. ha áttetszőség is van a dologban, akkor annak a mértékét szokás ott tárolni :).
SDL leírás:
Magyarul csak ezt találtam, de a angolul rendes fejlesztői leírást, példákat, stb. találhatsz az oldalukon.
Köszi az eddigi segítségeket, máris átgyúrtam kissé, pld a görberajzolás helyett megjelenít két ronda, pixeles "Á" betűt. Azt hiszem a hétvégén alaposan nekiesek. A ksdl-t egyelőre nem nyaggatom, elég egyelőre az SDL is, nem lehet mindenbe egyszerre belevágni... Mégegyszer köszi mindent! Innentől már a legfontosabb azt hiszem a sok-sok szorgalom...
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Nem világos előttem, hogy itt:
Uint32 timer(Uint32 interval, void *param)
{
static double t = 0;
printf("time: %f\n", t);
fflush(0);
t += 0.1;
return interval;
}
mi célt szolgál az "interval" és a "param" paraméter, amikor nem is használja őket!
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Az 'interval' az SDL_AddTimer() első paraméterében megadott időzítési érték, azért van rá szükség, mert ennek a 'timer' rutinnak vissza kell adnia, hogy a futása után mennyivel később kéri a köv. ráhívást, és ha egyenlő időközönként szeretnéd hívatni, akkor ugye ugyanazt az értéket kell visszaadni - és ha már egyszer megmondtad az AddTimernél, akkor miért kelljen külön tárolnod :).
A 'void*' param azért van, hogy te magad is tudj általad tetszőlegesen felhasználható adatot csatolni az időzítéskéréshez, ugyanis ez a mező azt kapja meg, amit az SDL_AddTimer() utolsó paraméterének megadtál.
Ez arra jó, hogy ha pl. játékot írsz és a szörnyeket mozgatod időzítővel, akkor tudsz ilyet csinálni:
Ezzel ugyanazt a timer rutint használhatod a szorny_t típus összes példányának a mozgatására, ugyanis a rutin az utolsó paraméterben megkaphatja az aktuális példány mutatóját. Félig-meddig ez már oop :).
Ha jól értettelek, ez a sor:
SDL_AddTimer(100, szorny_leptet, sz[i])
ez minden ciklusban mintegy "átírja" a timer rutint, úgy értve, hogy más paramétereket ad neki. Lehet hogy még megboldogult C-64 -es korszakomból származó "életérzés" (de abban nagyon benne voltam: a "gépi kódján" saját programnyelvet írtam hozzá...), de számomra szimpatikusabb megoldásnak tűnik, és talán az OOP szelleméhez is közelebb áll, hogy a main indulásakor aktivizáljuk a progi élete során egyetlenegyszer a mi "megszakításrutinunkat", azt tehát amit a timerre kötünk, s ez mindig amikor meghívódik teszteli hogy van-e épp dolga. S hogy mikor melyik szörnyet kell mozgatnia (ha ez a feladata) azt pld globális változón (tömbön) át tudja meg, hogy ha mondjuk egy bit vagy bájt 1, akkor léptetnie kell a kis szörnyfickót. Mert ugye a szörnyek sebessége is lehet eltérő... A tömb természetesen
szorny *
típusú elemekből állna, ahol a szorny egy osztály. (class). És nyilván lenne neki valami publikus függvénye ami visszaadja, kell-e épp mozgatni. Bár ha sebességkritikus a dolog, ami ilyene setben nem kizárt, érdemes talán az ezt jelző változót is public-ká tenni, és nagyon ügyelni rá, hogy azt még olvasni is csak a timer rutinunk olvassa.
Egy kérdés: ez a sor:
SDL_AddTimer(100, szorny_leptet, sz[i])
Ha ezt meghívom másképp, mondjuk így is:
SDL_AddTimer(20, IRQ, valami)
akkor azt jelenti, hogy lesz 2 különböző timerem is, egy szorny_leptet nevű is ÉS ugyanakkor egy IRQ nevű is? és mindegyik lefut, egyik 100, másik 20 milliszekundumonként?
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Különben meg _természetesen_ OOP-ben progranyozok - de az Űrboszorkány valagára is, hogy én mit szopantyúztam! ennél: SDL_AddTimer(100, szorny_leptet, sz[i])
nem adtam vissza az intervallumot kilépéskor, s emiatt csak 1-szer frissítette nekem a grafikus képernyőt! S én egy egészen más rutinban keretem a hibát, abban ami a billentyűzetet figyeli. Mert miért nem jelenik meg a lenyomott billentyű nekem a képen... persze a hiba a megjelenítésben volt. Vagy hat órán át kerestem a hibát, míg végre tegnap éjfél felé rájöttem...
No most az eddigiek egy alapos ujjgyakorlat volt csak nekem az SDL-t illetően. Most megírom a magam STRING osztályát, figyelembe véve hogy annak lesznek kapcsolódásai a már eltervezett SPRITE és FIXFONT osztályokhoz meg egyebekhez is, meg rá kell jöjjek, miként kezelhetek az SDL-el png képeket, meg Ogg Vorbis fájlokat, szóval lesz sok dolgom. Utóbbiakhoz találtam angol leírást, csak kérdéses hogyan boldogulok el velük.
Ja, ne is ajánlgassatok string osztályokat mert szerintem mire egy másik osztálykönyvtárat jól megértek, majdnem annyi mintha megírnám magam. És különben is speciális stringeket akarok, valahogy így nézne ki:
#define USI unsigned int
#define USC unsigned char
class STRING {
USI maxhossz; // ennyi van lefoglalva maximálisan a string részére,
// záróbájt nélkül. A záróbájtot NEM TÁROLJUK. (felesleges).
USI akthossz; // Ennyi az éppen használt terület a maxhosszból.
// Ha akthossz>maxhossz, akkor baromi nagy gáz van.
USC *s; // Na itt lesz letárolva a lényeg
};
Ennek pld az a lényege, hogy amikor operatoroverloading esetén meglesz az '=' átdefiniálása, vagy épp a '+'-é, nem kell mindig új memóriaterületet allokálni, elég csak akkor, ha az új string hosszabb mint maxhossz, különben elég bemásolni a már rég lefoglalt területre. Ez pld meggyorsíthatja a futást.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
úgy értetted:
typedef unsigned int USI;
typedef unsigned char USC;
a #define utasítást pedig a feltételes fordítást leszámítva lassan ideje lenne elfelejteni. Néha kell, de ez nem az az eset.
USI maxhossz; // ennyi van lefoglalva maximálisan a string részére,
// záróbájt nélkül. A záróbájtot NEM TÁROLJUK. (felesleges).
Ezt gondolom úgy gondoltad:
USI maxhossz; //záró bájt nélküli maximális hossz,
Ember legyen a talpán, aki egy idő után átlátja ezeket.
// Ha akthossz>maxhossz, akkor baromi nagy gáz van.
Ez meg ugye vicc? Ez nem fordulhat elő. Osztályt használsz, ezért a belsejét az osztály tagfüggvényei érik csak el, ezáltal biztosított, hogy ez az eset sosem fordulhat elő, mert már előbb tiltakoznak e függvények, természetesen megfelelő formában (visszatérési érték, kivétel - az utóbbi a jobb).
Egyébként meg használj std::string-et, már megírták helyetted. Tutira gyors, garanciák vannak a sebességre.
Az akthossz>maxhossz csak félig vicc. Nyilván, kívülről nem macerálhatom e változókat (mert nem vagyok olyan hülye, hogy publicnak adjam meg őket), de mi a garancia rá, hogy a tagfüggvények írása közben nem követek el hibát?
Mindenesetre csak amiatt írtam le hogy jelezzem, erre lényeges ügyelnem az osztály megírása közben.
A #define alkalmazásával az USI-ra és USC-re nem értem mi a gond. Nekem tökéletesen működtek eddig mindenhol.
Különben amire én baromira haragszom az az, hogy állandóan kínlódnom kell vele, hogy egy nyamvadt char, az alapértelmezésben előjeles. Volna-e valami mód, pld fordítási opció, ami által az összes char-t rögvest úgy tekintené hogy az mind unsigned? De persze minden könyvtári függvénye jól működjön ettől... Számomra az a természetes, hogy a char, az 0-255 közti pozitív egész számokat tárol. Pláne mert főként KARAKTEREK tárolására használom, vagy legalábbis bájtokéra, és soha még elő nem fordult nálam, hogy előjeles bájtra lett volna szükségem!
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
A karakter: igazából mindegy, előjeles-e, vagy sem, ugyanis nem számokat tárolsz benne, hanem karaktereket. Ha számokat akarsz:
typedef unsigned char byte;
vagy a kernelnek megfelelően:
typedef unsigned char u_int8_t;
A #define-nal az a baj, hogy nehéz vele hibát keresni, hiszen a gcc nem is ezt fordítja le, hanem az előfeldolgozó által átalakított változatot (gcc -E -o almafa.kimenet almafa.c paranccsal ugyanazt kapod, amit valójában fordítani fog).
A konstansok, típusok csak a forráskódban léteznek, amint lefordítod, azonnal teljesen más kerül a helyére, tehát elég nehezen fogod tudni megkeresni a hibákat például gdb segítségével.
De bizony hogy én számokat tárolok a char (illetve unsigned char) változókban! Egyszerűen pszichológiailag sem vagyok képes másképp tekinteni rájuk, mint picike kis rekeszekre, amikbe apró számok férnek. Az hogy ezek adott esetben karakterek kódjaként vannak ÉRTELMEZVE, már egy merőben más kérdés. Végredményben ha nem számok lennének akkor hogy is hasonlíthatnám össze őket számokkal, hogy az adott karakter pld egy bizonyos tartományba esik-e?! Hogy az adott char változóm épp számnak van-e tekintve vagy karakternek, az őt feldolgozó rutintól függ. Ha olyan kedvemn van s egy char változót kiiratok, a képernyőn megjelenik valami karakter, ami az adott (változóban tárolt) kódtól függ. Más esetben a char változó lehet akár számláló is nálam, vagy valami tömb indexe, akármi.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
ööö, ki mondta, hogy az 'a'..'z' intervallum pusztán 26 számot tartalmaz? Nem csak ASCII kódolás van. Egy utf-8-as karakter bele sem fér a char típusba. Hogy tudod összehasonlítani?
Túl sajátosan gondolkodsz, így másnak nehéz lesz az általad megírt kódot megértenie. Tömbindexelésre használt char típusú változó több, mint furcsa.
De mi van ha nekem elég az ISO-8859-2 kódolás?! És ezesetben pld felvehetek egy tömböt, ami 256 elemű, s mindegyik bájtja infókat tárol bitmezőben az adott karakterről, pld:
BIT
0: bináris számjegy (0 vagy 1)
1: decimális számjegy
2: hexa számjegy (0-9, a-f, A-F)
3: angol ABC eleme
4: magyar ABC eleme (tehát az ékezetes betűk is)
5: NAGYbetű (beleértve az ékezeteseket is)
6: whitespace karakter
stb.
S ennek logikusan a karakter 1 bájtos kódja lehet az indexe, majd egy megfelelő AND kapcsolat és tudom a választ, milyen típusú a karakter.
Ez egy lehetséges jó felhasználása a karakternek mint tömbindexnek.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Nem kell nagyon megerőszakolnod magadat, hiszen valójában az esetek többségében teljesen indifferens, hogy ISO-8859-2-ben az 'á' kódja 160 vagy -31.
Két karakter egyenlőségét tudod ellenőrizni, 'a'-'z' intervallum ugyanott van, de úgyse használod, mert nem működik ékezetes betükre, illetve ott van az isalpha és hasonlók, ami még kezelheti is akár az ékezeteket.
Abban megegyezhetünk, hogy az indexelés elég ritkán kell, de amikor meg igen, akkor odaírsz egy unsigned típuskényszerítést és kész:
Elsőre nekem is furcsa volt, de igazából tényleg teljesen mindegy.
A GUI szerkesztők tekintetében osztom a nézeted, tényleg elfedik a dolgok működését ami nem feltétlen jó.
Épp ezért szoktam ajánlani a Qt-t, illetve azt, hogy az első pár alkalmazásban kézzel szenvedje össze az ember a felületet.
Majd miután megtanulta mi hogyan működik, akkor jöhet a Designer, ami tényleg felgyorsítja a fejlesztést. De közben mindig meg lehet nézni a generált forrást ami tényleg szép, szinte mint a kézzel írott lenne.
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Félreértés ne essék, elismerem a GUI-szerkesztők létjogosultságát, páne ha a gyors programfejlesztés fontos. De én (sajnos) nem programozásból élek. Nekem egy ilyet megtanulni úgy érzem iszonyatos meló volna, mert az egész gondolkodásmódomat meg kéne erőszakolnom.
Mellesleg, nem vagyok benne biztos, nem pazarolják-e az erőforrásokat. A dolog arra emlékeztet engem, amikor még DOS alatt írtam egy rutint C nyelven, azaz inkább több kisebb rutint és egymást hívogatták. És aztán később át akartam ezeket tenni valamiért assemblybe de mert lusta disznó vagyok, gondoltam abból indulok ki, amit a fordító generál, azaz megnéztem az előfordított assembler source-ot nekije. És elszörnyedtem attól, amit láttam... Még a veremkeretet is pocsékul kezelte.
Megírtam inkább magam natúr az egészet assemblerben.
Jut eszembe: most helyesen assembly vagy assembler? mert mindkettővel találkozom gyakran...
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Van QUI szerkesztő ami pazarolja az erőforrásokat, van ami nem.
A Qt4-es jó. És tényleg nem csinál mást, csak a felületet, az irányítás a programozó kezében marad.
Másban én is kézzel csináltam többnyire. :)
Minden gyorsabb assemblyben, csak nem mindent érdemes abban írni. Sőt egyre kevesebb dolgot.
Assembly a nyelv, assembler a program ami lefordítja.
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
Abban persze igazad lehet, hogy sajátosan gondolkodom. Ennek talán az is oka lehet, hogy én 42 (lassan 43) éves vagyok, s még a C-64 korszakában kezdtem programozni, annak gépi kódjában. Később a PC-ket is programoztam (DOS alatt) Assemblyben, írogattam benne rutinokat amiket hívogattam C nyelvből. Számomra tehát nem idegen a gépközeli gondolkodásmód. Számomra vannak különböző hosszúságú (bájtdarabszámú) memóriarekeszek, aztán hogy ezek épp minek vannak tekintve, a megfelelő szubrutintól illetve alprogramtól függ. Az OOP-t is szeretem, nagyon tetszik, de például hogy e gondolkodásmódom negatívumaira is önkritikával rávilágítsak, a mai napig leküzdhetetlen nehézséget jelentett nekem az a fajta programozás (egyszerűen nem tudtam megtanulni...) hogy valami program van amiben holmi formokat meg ikonokat dobálgatok valami keretbe, s ebből a progi valami misztikus módon összerakja nekem az én programom kódját, benne a gombokkal, görgetősávokkal, stb. Egyszerűen nem értem az egésznek az elvét, tök idegen a számomra, ahelyett hogy egyszerű volna, rém bonyolult! Számomra a programozás, kissé talán régimódiasan, az, hogy megtervezem mit akarok, megírom a kedvenc szövegszerkesztőmmel, aztán lefordítom és kipróbálom.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
azt hiszem, összemosol dolgokat. Az OOP és a "gyors alkalmazásfejlesztés" nevezetű csoda (Borland Delphi meg egyebek hirdetik magukat így) nem ugyanaz. Ráadásul nem is misztikus, mert ha én megírok egy assembly vagy egy más nyelvű kódot, akkor az is eléggé misztikusan hat, hogy mondjuk egy másik szerverrel kommunkál az interneten, kábelen, vagy éppen levegőben, mikor hogy. Ez nagyon szubjektív. A fejlesztőkörnyezet segítséget nyújt a kód megírásához, mondjuk mint egy-egy shell szkript, ami vár pár paramétert, és azoktól függően csinál meg dolgokat.
Asszem félreértettél, Panther: Tudom, hogy az OOp nem azonos a mindenféle alkalmazásfejlesztő izémizével! Most is OOP-ben programozom, ma délután pld megírtam a magam STRING osztályának alapdolgait (konstruktor, destruktor, másolókonstruktor, meg az olyan operator overloadingokat hogy index operátor, =, +), még hátra van az összehasonlító operátorok, meg az stdin/stdout kezelése, de talán éjszakára vagy holnapra hagytam.
Az OOP-vel tehát semmi bajom önmagában. Az ezt segítő grafikus fejlesztő-kutyulmányokat nem tudtam csak megtanulni.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
"Az OOP-vel tehát semmi bajom önmagában. Az ezt segítő grafikus fejlesztő-kutyulmányokat nem tudtam csak megtanulni."
Na igen :) Én pl. emacs/vim editorokat használok, semmiféle extrát. No persze guit sem nagyon programozok :)
Nos, utánanéztem kicsit ennek a "ksdl"-nek.
Olybá tűnik, hogy a Kandósok közül valakinek eszébe jutott, hogy haladni kéne a korral, és leimplementált egy olyan függvény-réteget az SDL fölé, ami funkcionalitásában és életérzésében kissé a jó öreg TúróPaszkál graph unit-jára emlékeztet :).
Nem rossz az elgondolás, figyelembe véve, hogy ez főképp olyan embereknek készült, akiknek sokkal fontosabb, hogy _mit_ jelenítsenek meg, mint az, hogy _hogyan_.
(Mondjuk én az SDL-t önmagában is merném ajánlani, de ez már ízlés dolga. Ha netán valami 'elitebb' intézmény hallgatója kifogásolná, csak kérdezd meg, hogy hogy is áll mostanában a Comenius Logo :)...)
Szóval a ksdl honlapja itt van.
Makefile:
CFLAGS=-ggdb `sdl-config --cflags`
CXXFLAGS=${CFLAGS}
LDFLAGS=`sdl-config --libs`
All: hello
#ha hello.c vagy hello.cc tartlamazza progidat.
sima make -el fordul
Egy régi könyv: http://pil.pl/~mariuszj/rozne/plg-second-printing-update.pdf
NeHe oladala is ajanlott, ha OpenGL -re fanyalodnal.
Tárgytalan, "the problem is solved". Töröltem a hozzászólást.
Én csak egy címváltást javasolnék, mert megtévesztő a jelenlegi. Ez a téma nem a grafika programozás, hanem grafikus felhasználói felület (GUI) készítés.
Nem érzem a különbséget a kettő közt. A GUI alapvetően grafikákra épít.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
grafika: OpenGL, SDL, DirectX és egyebek segítségével alkotott kép, lásd pl. Quake3, OpenTTD és egyebe. GUI: gtk, qt, wxwidget és egyéb függvénykönyvtárakkal készített interaktív felület, amilyen pl. a firefox-nak van. Egészen más.
Ebben természetesen igazad van, de ne feledd el, hogy a grafikához is kell mindaz, amiről e topikban szó van, mert itt az egésznek a legalapabb alapjairól van szó, és épp ezért ez kell a GUI-hoz is, mert hol jelenítesz meg te grafikát, ha nincs grafikus felület!
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó
Akkor lehetne "Kijelző építése" is a cím, mert hol használsz grafikus felületet, ha nem egy kijelzőn... /o\
Nem igaz. A grafikának az alapja a pixel, pont, vektor, geometriai transzformációk, a sugár, a spline, az illumináció, képszintézis, ilyesmi. Meg a fizika.
Ehhez nem kell grafikus felhasználói felület, csak egy videókártya.
Legalább a belinkelt wikioldalt nézd meg. Vagy ezt.