[kalvis]

[Ho Ho]

kalvis, enamus assemblerikäske on otse c's kasutatavad intrinsic'ute näol mida saad muu koodi vahele torgata täpselt nagu suvalisi muid funktsioone kuid kuna kompilaatoril on märksa vabamad käed nendega ümber käimiseks siis suudab ta neid ka optimeerida. Otse ASM'i kirjutades seda teha ei saa.

[kalvis]

[andreie]

[taurib]

Tundub, et see C keele kirjutamine MSVSis on ikka päris suur jamamine, ma saan siiski pigem Geany'ga hakkama :/
Vähemasti ma leidsin igasugu keerulisi õpetusi, kus peab midagi seal CMD promptis ära tegema ja selle siis siduma selle MSVSiga kuidagi moodi

[andreie]

Oops. Olen unustanud öelda, et saab ka väga lihtsalt - teed C++ projekti, aga uute failide lisamisel märgid käsitsi faili laiendiks ".cpp" asemel ".c". Siis käib kõik automaatselt, kompilaator piirdub vaid C keele võimalustega jne.

[Supiplex]

Ma julgen väita, et algaja huvilise jaoks pole küll IDE esmatähtis. Esiteks seetõttu, et kuni paarituhande realise C programmi jaoks pole IDE overhead kuidagi vajalik. Teiseks seetõttu, et nii õpib tööriistu paremini tundma.

Kompilaator, süntaksit värvida oskav tekstiredaktor (Notepad++, Programmers Notepad) ja make nõuavad alguses väikese õppimiskõvera ületamist, aga tasuvad hiljem kuhjaga ära. Jäävad ära igasugu totakad projektiwizardid, sättungitest kompilaatori optionite otsimine, kummaliste projektistruktuuride järgi paindumine jne.

[kalvis]

Sai lõpuks järgi proovitud ... ja asi toimib. Üksjagu pusimist oli enne kui sai piisavalt netist see teisenduste olemus selgeks tehtud.
Lisaks leidsin otsesed näited Hi-Low baitide ümbertõstmisest ja mis seal salata, nüüd on muudki optimeerimised tulemas. Saan palju lihtsamini mälumassiivide kirjetel just mind huvitavaid täisbaite lugeda. Tuleb vaid õieti viitade tüüpidega mängida ja nende aadresse arvutada. Enne sai liiga palju bitinihetega liigutatud, nüüd pole vaja. Bitmaptöötluses mõned nihked jäävad ikka.

Lõppkokkuvõttes tegi kurvaks, et koodi kirjutamine ei ole protsessorist ega keskkonnast täiesti sõltumatu, mida võiks kõrgkeelelt rohkem oodata. Kuid kuna minu mänguruum jääb esialgu Intel prosede juurde siis mulle probleemi sellest ei teki.

[Ho Ho]

[kalvis]

Miks mitte. Aga kuhu ja kuidas. Tuleks teha eraldi teema ja kuhugi link siis programmi kättesaamisele. Kuskil peaks server olemas kus siis kood pesitseks ja saaksime faile üles riputada. Ma kolisin oma koodil tagasi C keskkonnale, peapõhjus oli selles, et C -s kirjutades ei tulnud asi raskem välja, C-s olid aga põhilibrarid (OpenGL, SDL, akendevärk toetatud). Ja mis seal salata, C-s kirjutasin oma esimese programmi 15 aastat tagasi juba aga C++ alles nüüd. Harjumus on suur. Eraldi tuleks veel skriptikäskude formaati arendada, ideid on kilokaupa, igaühel omad plussid ja miinused. Esmane eesmärk on siis vaja saada tööle failist interpretaator - failis on graafiliste primitiivide käsud koos andmetega ja joonistab siis kas 2D-s või 3D-s. Praegu asendasin selle otsese OpenGL formaatide toega, momendil joonistab OpenGL failist otse primitiive. Et failiks võib kasutada kõiki tuntud vabavaralisi 3D vidinaid ja joonistab (algnäited olid Nehe jt. variandid), kuid ma modisin nende koodi veelgi lühemaks ja dünaamilisemaks ja otse omavahel kasutatavaks. Loomulikult saab asja ka C-s otse kasutada, ei pea intepretaator olema, seal kutsud välja vastava funktsiooni otse. Momendil on toorkood olemas bitmapfailide laadimiseks ja AVI striimide kasutamiseks... ja ka vastupidi - skript võimaldab valmistehtud ka mõnda muude faili panna (salvestamine, ümberkodeerimine). Et interpretaator võimaldab ka kõiki videosi läbisegamini piltide, tekstide jne. kasutamisega või kasvõi mõnel oma lemmikfilmi vaadata (eesmärk ei ole VLC-d kirjutada, lihtsalt ta võimaldab seda minimiseeritult skriptina kasutada).

Ma umbes pool progemise ajast kulutan optimiseerimise ja multimeedia formaatide kohta infot otsides. Ühest kohast oli meeldiv teada saada, et C-s enam niiväga koodi kirjutades optimiseerimisele mõtlema ei pea, kaasaegsed paralleeltöötlus võimaldab ka halvasti optimiseeritud koodi maksimumis joosta. Eelkõige huvitab just C-s (C++) optimiseerimine, kasvõi kõik üldpõhimõtete kohta linkide saamine. Näiteks, kui dünaamiliselt mälu võtan siis idee järgi teatud blokid ja õigete andmetega lähenemine meeldivad kompilaatorile rohkem ja annavad kiirusevõitu. Vot ma siis nende blokkide kaupa mälu võtaksingi (praegu võtan 4 kB kaupa või sellega jagunevalt). Ja teine on koodis tarbetud muutujate teisenduste minimiseerimine.

Eraldi teemana huvitaks mind otse andmete saatmine videokaarti või nii otse kui võimalik. Lähim mõiste on linear framebuffer, kuid soov on ka sellega seotud kõiki muid parameetreid näppida niipalju kui vähegi saaks. Kui videokaartide programmeerimine on kellelgi käpas siis väga ootaks, DOS ajastu oma oskan, kuid tänapäeva op.süsteemid seda meetodit ei luba. Miinimum oleks Linuxis asi tööle saada, Windowsis mõned ideed on kuidas saaks.

[matik]

[andreie]

[kalvis]

SDL ammu kasutamisel, kuid lugesin, et nad ise ei pääse otse videokaardile ligi vaid kasutavad Windowsis windowsi API-t (directX-i). SDL on praegu just universaalsuse nimel kasutusel, esialgu ajab asja ära. Niipalju olen leidnud, et DirectX-ga pidi saama palju lähemale, peaaegu et otse (datat saab kirjutada ja lugeda), kuid mitte ramdaciga seotud parameetreid. Kahjuks pole seni leidnud puust ja punaseks näidet, et kuidas siis directx saaks kas akent või täisekraani jagu lihtsalt viidaga mälubloki videokaarti saata. Arvan, et niipea ma rohkem ei tahagi, kuigi lõppunistus oleks ka videokaardi ramdac custom modes teha (vaja just videode veavabaks presenteerimiseks).

Vahepeal tekkis uus probleem. On keegi Mesa edukalt windowsil kompileerinud, probla selles, et katsetamisel kasutatavad arvutid on nõrga OpenGL toega ja saadavad mind riistvaras pikalt. Softis on aga tugi vaid 1.1 -le, MESA annaks aga 2.1-le, millest mulle on isegi ülearu. Kompileerimine läheb algul justkui käima (MESA 7.4) kuid pika töö järel annab nii error 1 kui error 2 MinGW-ga kompileerimisel. Ainus vihje on seni, et Makes on vist mingi bug, mistõttu mingi (ma_types.exe???) exe asjast ja tema asukohast kompileerimisel tekib tõrge. MESA sellid on kõik teinud, et keegi nende softi kohta mingit abi ei saaks. Teised uuemad MESA versioonid ei jõua algreast kaugemale, error 1-ga, vist linkimise kataloog (no ei ütle mis faili tahab saada). Kui saaks toimima siis piisaks mul enamuses vaid SDL-ist ja OpenGL-ist, kui aga mitte siis, eks siis tuleb OpenGL asemel DirectX-le kolida, esialgu ei tahaks seda teha.

Heli, praegu piisab SDL-ist, kuid kummale tasuks rohkem panustada - kas DirectX-le (Directsound) või OpenAL-le? OpenAL API uurides ei leidnud ma sealt midagi vaimustavat ja kommentaarid olid vähelubavad. Perspektiivsem tundus DirectX (kuna video tuleb vist sellele nagunii viia kuna OpenGL ei taha kuidagi toimida) sest praegused multimeedia tegelased kasutavad just seda.

[Ho Ho]

Räägi mida sa täpselt saavutada üritad selle otsese ligipääsuga ning miks standardlahendused (a'la opengl'i ram'is elavad tekstuuride majandamise extensionid) ei sobi. Hetkel jääb mulje, et lähened probleemile väga vale nurga alt ning raiskad üüratus koguses ressursse lahendamaks probleemi mille ise tekitasid kuna ei tea kuidas GPU'd kasutada

Mesa otsene kasutamine on sarnaselt kummaline ettevõtmine kui sul on sama funktsionaalsus (ja palju enamatki) saadval standartsete GPU'ga kaasa tulnud draiveritega ning seda koos korraliku riistvaralise kiirendusega.

Heli koha pealt pigem vaataks openal'i. Ka päris suured-tuntud mängude tegijad eelistavad toda kõiksugu muudele alternatiividele.

[kalvis]

Vaja oleks ligipääsu PAL videostandardile vajaliku VGA signaali genereerimiseks. Kuid miksiksin kokku nii video kui ka muud 2D ja 3D elemendid, seejuures osa datat võib tulla ka võrgust ja saadetakse sinna ka tagasi. St. arvutist saab multimeediakeskus otse teleka taga ning datat sisse ja välja tuleb nagu Linuxis tavaline kõikjalt (peamiselt pult, hiir, klaviatuur ja võrk). Bitmapis tuleksid juhtmenüüd ja muud asjad. Klient ja server ei pea üldse asuma samas võrgus, võivad täitsa vabalt asuda kasvõi erinevates riikides.
PAL-le on vaja moonutusevabalt nii täpset sünkroniseerimist, üleridade õiget data saatmist. Praegused meediaplayerid windowsis seda ei võimalda, Linuxis võimaldavad. Esimeses etapis rahuldabki, et server saab olema Linuxis ja tõenäoliselt klient on Windowsis või nutitelefon. Mõlemal programmil peab olema samad objektid ja töötlus. Kuna kasutan üle võrgu juhtimist ja virtuaalset pildi vaatamist siis peab programm olema võimeline töötama mis tahes op. süsteemis.
Loomulikult saab samu asju kasutada kasvõi mängude progemiseks või lihtsalt arvuti kaughalduseks, neis pole videokaardile otsest ligipääsu vaja.
Videotöötlus on väga ressursimahukas, seega on vajalikud kiired algoritmid.

[Ho Ho]

Kõlab äärmiselt huvitava ettevõtmisega.

Kas on mõni mõjuv põhjus miks sa lihtsalt sisse tulevaid kaadreid videomälu tekstuurile ei kopeeri, sinna otsa kõiksugu vajalikke imevidinad renderdada ja too tekstuur vabalt valitud resoga (PAL) edasi saata? Kui sa just otseselt PAL'i signaali sisse mingit lisainfot ei kodeeri siis töötaks selline asi igati normaalselt. Mingit sorti moonutusi sealt sisse ei saa tulla ning interlaced outputi eest hoolitseb raudvara automaagiliselt.

[kalvis]

Ma olen selle VGA -> PAL vidinaga mässanud. Pilt on parim teadaolevatest, kuid ikkagi on moonutused sees. Nüüdseks on selgunud, et veapõhjuseks on valel ajal data saatmine videokaarti, seda tuleb teha sünkroniseeritult vastavalt kiire tagasijooksmise hetkel kaadrivahetusel ja tuleb veel arvet pidada paaris ja paaritu kaadri osas. Oluline on ajastus, data peab saabuma ainult kiire tagasijooksu ajal videokaardi mällu ja hiljem tuleb just blokkida. On ka veel muid lahendusi, kuid kõigel on omad vead. See saatmine on kõige lihtsam ja kiirem lahendus ja tegelikult ei nõua midagi erilist.

[andreie]

Kalvis, ehk saad järje peale siit: IDirectDraw7::WaitForVerticalBlank method.

[kalvis]

See oli justkui tõesti see, mida otsin. MS DirectX on võimas multimeedia librarid, kuid maht on ka võimas. Õppimine võtab kaua aega, leidmine veelgi rohkem.
Vahepeal otsisin DirectX kasutamise võimaluste kohta Linuxis, kas tõesti pole mitte keegi viitsinud seni teha ühtegi DirectX API-ga librarit, mis töötaks otse X serveris? Wine jaoks on olemas? Otse X serverile mitte või ma ei leidnud ühtegi viidet.

[neros]

Ahem... DirectX'l pole X'ga mitte midagi pistmist. DirectX on Windowsi eksklusiivne API. Wine peal mingi DirectX'i emulatsioon töötab, aga ma ei usaldaks seda 100%liselt. Linuxi all natiivselt töötavat DirectX'i loota on naiivne. Kui sa tahad midagi mis ekraanile paneks asju, siis OpenGL ongi enamvähem üks ainukesi linuxilisi.

[LiivaneLord]

Kas keegi oskab soovitada mingit programmi, mis suudaks konstruktsioone (if, for, foreach, while jne) taandega esile tuua? Notepad++, Editplus ja paljud, mis olen proovinud, suudavad seda küll teha, kui kirjutan järjest, aga kui vaja midagi muuta, siis nad ei suuda õiget asetust taastada.

Praegusel juhul on vim selles suhtes ideaalne, aga see on krdi tagasihoidliku välimusega programm ning ei sobi mulle. Vim loob taanded õigesti.

[HellWalKeR]

[LiivaneLord]

HellWalKeR, tänan vastamise eest. Eile pika googeldamise ja mitme programmi installimise peale leidsin suurepärase programmi, Sublime Text 2. Reindent käsk loob oma koodud koodist vaat et kunstiteose ning kõik konstruktsioonid on kenasti eraldatud ja neid on võimalik ka kahandada. Kõige parem on see, et valides kogu teksti, luuakse kõik taanded ja programm suudab arvestada ka HTML tagidega.

Otsimise ajal oli küll vahepeal tunne, et otsin midagi võimatut, sest kõik programmid kasutasid automaatset taandamist ühtviisi vigaselt.

[Ho Ho]

Vähegi asjalikemates IDE'des on kasutuses confitav koodiformaatija. Väga tahad võid ka ise miskit astyle'i põhjal kokku leiutada. Viimast kasutab baasina ka qt creator.