Moi!
Tarvitsisin kirjaston/koodinpätkän, jolla voisi käsitellä näyttöä. Vaatimukset:
Se ei saa olla dynaamisesti linkattava kirjasto, vaan joko staattinen kirjasto(.lib) tai pelkkiä koodinpätkiä. Sen pitää olla mahdollisimman alustariippumaton (eli tietysti tarkoittaa sitä, että kannattaisi toimia linuxissa, unixissa, wintoosalla jne...)
Linkitys ei taida olla niinkaan kirjaston ominaisuus, vaan valinta, jonka teet ohjelmaasi kaantaessa. Eiko standardikirjaston tutut funktiot (printf, putchar, fuufuu) kelpaa tekstin ulostamiseen?
Onko erityista syyta miksi esim. SDL ei kelpaa?
Tämä voi vaikuttaa vähän hiustenhalkomiselta, mutta viestisi perusteella vaikuttaisi mahdolliselta, ettet ole ymmärtänyt asiaa oikein, joten seuraavasta selityksestä saattaisi olla hyötyä...
Et voi tehdä tuollaisia asioita C++:ssa alustariippumattomasti, koska se miten nuo toteutetaan riippuu nimenomaan alustasta, tarkemmin sanottuna käyttöjärjestelmän API:sta. Jos käyttöjärjestelmää "ei olisi" eli kirjoittaisit itse tähän liittyvää käyttöjärjestelmäkoodia (laiteajureita), niin toteutus riippuisi laitteistosta.
Se mitä tarvitset saadaksesi aikaan mahdollisimman porttautuvaa (eli "laitteistoriippumatonta") koodia, on jonkinlainen C++-rajapinnallinen kirjasto, josta löytyy toteutus mahdollisimman monelle alustalle. Hyviä vaihtoehtoja pikseligrafiikkaan saattaisivat olla esim. SFML ja SDL. Moderneissa käyttöjärjestelmissä ei ole tuollaista yksinkertaista jakoa "tekstitilan" ja "grafiikkatilan" välillä. Mihinkään kovin matalan tason "näyttöoperaatioihin" ei myöskään kovin helpolla pääse käsiksi (ihan tarkoituksella), mutta fullscreen-moodia voi ainakin SDL:llä käyttää.
SDL vaikuttaa noihin sopivalta, vaikka C-kirjasto onkin. Ainoastaan "Textin tulostus(tekstitilassa)" pitänee hoitaa jollain muulla kirjastolla, esimerkiksi juuri noilla standardikirjaston tutuilla funktioilla tai sitten edistyneempään ncurses- tai PDcurses-kirjastolla.
Melkein minkä tahansa kirjaston kohdalla voit valita linkataanko kirjasto dynaamisesti vai käännetäänkö staattisesti sisään. Joidenkin kirjastojen lisenssien ehdot taitavat tosin olla tiukempia staattisen linkityksen suhteen. Miksi dynaaminen linkitys ei kelpaa?
SFML on myös hyvin kätevä C++-kirjasto grafiikkaan, sillä saa hyvin nopeasti aikaan asioita jotka SDL:llä vaatisivat paljon boilerplatea tai erillisiä kirjastoja. En ole ihan varma, että kuinka kätevää tuo haluamasi pikselitason virittely sillä on.
Mutta SDL:hän on hirveä! Jos sillä yrittää pelleillä, niin se herjaa että "ohjelma ei voi toimia, koska sdl.dll puuttuu tietokoneesta"! Ja en voi (valitettavasti) käyttää dll:liä.
Älä sitten pelleile vaan käytä kunnolla. Ja mikset voisi käyttää DLL-tiedostoja?
Tukeeko linux dynaamisesti linkattavia kirjastoja? Tietääkseni ei tue. Korjatkaa jos olen väärässä.
Linuxilla DLL:iä vastaava tiedosto on .so eli Shared Object.
Toisinsanoen SDL kyllä toimii Linuxillakin...
Mutta enpäs sano enempää. Itse skippasin koko SDL:n ja käytän pelkkää OpenGL:ää kaikkeen.
Jos dynaamisesti linkattavat kirjastot jostain kumman syystä aiheuttavat närästystä, niin voi sen SDL:n staattisestikin linkata mukaan. Ei se vaadi kuin pieniä muutoksia makefileen. Hyvällä säkällä pelkkä -static parametri g++:lle voi riittää. Haulla löytyy netistä varmasti ohjeita.
Torgo kirjoitti:
– – niin voi sen SDL:n staattisestikin linkata mukaan.
Tästä tietenkin seuraa automaattisesti (LGPL:n ehtojen mukaan), että omankin ohjelman lähdekoodi on julkaistava, mistä Linux-käyttäjät ovat toki kiitollisia (jos nyt ohjelmasta yleensäkään voi olla kiitollinen).
Tämän ja eräiden muiden keskustelujen perusteella sanoisin kyllä, että ErroR++:n kannattaisi toistaiseksi unohtaa muut kielet ja opetella kunnolla edes yksi kieli sekä paljon itsenäisen tiedonhaun taitoa. Jos virheilmoitus "DLL-tiedostoa ei löydy" ei ratkea omin avuin, eväät ohjelmointiin (varsinkin C++:n kaltaisella kielellä) ovat aika heikot.
Metabolix kirjoitti:
Jos virheilmoitus "DLL-tiedostoa ei löydy" ei ratkea omin avuin, eväät ohjelmointiin (varsinkin C++:n kaltaisella kielellä) ovat aika heikot.
Se ratkesi eritäin nopeasti, kun tiesin missä .exe oli. Laitoin sen samaan kansioon sen kanssa. Ja hyvin toimi.
ErroR++ kirjoitti:
Se ratkesi eritäin nopeasti, kun tiesin missä .exe oli. Laitoin sen samaan kansioon sen kanssa.
Valitsit niistä kahdesta toimivasta tavasta juuri sen huonomman. Kun laitat jaetun kirjaston samaan haekmistoon exen kanssa, se ei enää ole jaettu. Nyt joudut kuljettamaan dll:ää jokaisen sitä käyttävän exe:n mukana. Homma on toki ok, jos jostain syystä haluat pitää kirjaston vain kyseisen ohjelman käytettävissä.
"En voi käyttää SDL:ää, koska koodaan Linuxilla" on aika huono selitys.
http://www.libsdl.org/index.php:
SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.
Torgo kirjoitti:
Valitsit niistä kahdesta toimivasta tavasta juuri sen huonomman. Kun laitat jaetun kirjaston samaan haekmistoon exen kanssa, se ei enää ole jaettu. Nyt joudut kuljettamaan dll:ää jokaisen sitä käyttävän exe:n mukana. Homma on toki ok, jos jostain syystä haluat pitää kirjaston vain kyseisen ohjelman käytettävissä.
DLL:n asentaminen systeemikansioon saattaa aiheuttaa DLL-helvetiksi kutsutun ongelman. Uuden ohjelman asennuksen jälkeen aikaisemmin asennetut ohjelmat lakkaavat toimimasta väärän DLL-version takia.
hohoo kirjoitti:
DLL:n asentaminen systeemikansioon saattaa aiheuttaa DLL-helvetiksi kutsutun ongelman. Uuden ohjelman asennuksen jälkeen aikaisemmin asennetut ohjelmat lakkaavat toimimasta väärän DLL-version takia.
Jep. Ja tuon takia sitä kansiota ei pitäisikään joutua itse sorkkimaan. Kehittyneemmissä käyttöjärjestelmissä ;) ongelmalta vältytään onneksi toimivan ja kattavan paketinhallintajärjestelmän ansiosta.
Aihe on jo aika vanha, joten et voi enää vastata siihen.