DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Je gaat al snel naar directX of openGL... Wat voor lijntjes will je tekenen? Win32 zal er misschien ook wat functies voor hebben, mits je in een formpje zit.quote:Op maandag 9 mei 2011 18:06 schreef netolk het volgende:
Hey Fokkers
Ik heb een vraagje hoe kan ik aparte pixels op het scherm tekenen of kleine lijntjes??
Ik heb al wat gekeken voor openGL maar dat is niet zo heel handig om een paar lijntjes te tekenen
Iemand suggesties om dit te doen?
Het liefst wil ik niet in Win32 werken... ik heb een paar tuts gevonden met openGL maar die gebruiken allemaal glut ofzo en dat is dan dus weer niet puur openGL
Beware of the Raping Zebra's
@ ralfie, in mijn vorige post was ik vergeten wat ik voor lijntjes wil tekenen
ik wel horizontale,verticale en diagonale (45 graden) lijnen tekenen van 1 pixel breed en 3 pixels lang. En daar wil ik er heel veel van
Moet openGL in een win32 omgeving of kan het ook draaien in console mode?
ik wel horizontale,verticale en diagonale (45 graden) lijnen tekenen van 1 pixel breed en 3 pixels lang. En daar wil ik er heel veel van
Moet openGL in een win32 omgeving of kan het ook draaien in console mode?
Beware of the Raping Zebra's
openGL kan zeker niet in een console, aangezien dat text-based is. Ik neem aan dat je wel onder windows werkt? (en niet linux, freebsd, mac, whatever?)
Dan zul je toch met Win32 of Glut aan de slag moeten (glut is een laag tussen win32 en opengl in, die windowing en messaging afhandeld).
Win32 heeft een SetPixel() functie, maar die is niet echt snel. Als het snel(ler) moet, kun je een off-screen buffer alloceren, en die met SetDIBits vrij snel naar het scherm blitten.
Dan zul je toch met Win32 of Glut aan de slag moeten (glut is een laag tussen win32 en opengl in, die windowing en messaging afhandeld).
Win32 heeft een SetPixel() functie, maar die is niet echt snel. Als het snel(ler) moet, kun je een off-screen buffer alloceren, en die met SetDIBits vrij snel naar het scherm blitten.
Hmm... kut k vind die win32 dingen altijd zo'n gedoe om alleen al een window te krijgen...quote:
openGL kan zeker niet in een console, aangezien dat text-based is. Ik neem aan dat je wel onder windows werkt? (en niet linux, freebsd, mac, whatever?)
Dan zul je toch met Win32 of Glut aan de slag moeten (glut is een laag tussen win32 en opengl in, die windowing en messaging afhandeld).
Win32 heeft een SetPixel() functie, maar die is niet echt snel. Als het snel(ler) moet, kun je een off-screen buffer alloceren, en die met SetDIBits vrij snel naar het scherm blitten.
nouja het moet dan maar en k heb ondertussen de juiste code voor een lijn in openGL gevonden dus dat is opgelost
bedankt
Beware of the Raping Zebra's
OpenGL is ook voor 2D werk handig, omdat het gebruik maakt van de hardwareversnelling van je GPU. Het enige nadeel is dat het in eerste instantie wat complexer is.
Je kunt als je perse met OpenGL bezig wil ook prima met C# of Java aan de slag trouwens.
Je kunt als je perse met OpenGL bezig wil ook prima met C# of Java aan de slag trouwens.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Ja, en dan de rest van mn programma helemaal ombouwen zeker Xdquote:
OpenGL is ook voor 2D werk handig, omdat het gebruik maakt van de hardwareversnelling van je GPU. Het enige nadeel is dat het in eerste instantie wat complexer is.
Je kunt als je perse met OpenGL bezig wil ook prima met C# of Java aan de slag trouwens.
Nee, ik maak er wel gewoon een win32 app van en dan gewoon openGL voor het tekenwerk
Beware of the Raping Zebra's
Hey, ik heb een vraagje is het mogelijk om in een console programma de toets-status te onderscheppen??
ik gebruik nu GetAsyncKeyState(VK_UP) programma registreert het wel maar na het afsluiten kom ik er achter dat cmd het ook nog registreert en dan dus allemaal andere commando's (die daar voor gebruikt zijn) gaat uitvoeren, weet iemand hoe ik dit kan voorkomen in een console programma?
ik gebruik nu GetAsyncKeyState(VK_UP) programma registreert het wel maar na het afsluiten kom ik er achter dat cmd het ook nog registreert en dan dus allemaal andere commando's (die daar voor gebruikt zijn) gaat uitvoeren, weet iemand hoe ik dit kan voorkomen in een console programma?
Beware of the Raping Zebra's
In principe is dit niet mogelijk met standaard C(++). Het opvangen van toetsen is namelijk os-specifiek (invoer kan immers alleen in C(++) gelezen worden nadat de terminal het naar cin stuurt).quote:
Hey, ik heb een vraagje is het mogelijk om in een console programma de toets-status te onderscheppen??
Er zijn wel os-specifieke libraries die omgang met de terminal versoepelen, waarbij curses de grootste is in Unix-omgevingen. Ik heb curses voor iets dergelijks gebruikt, dus ik weet dat het hiermee kan. Ik lees ook net op de wiki-site dat het blijkbaar naar Windows geport is, dus wellicht dat je hier iets mee kan.
"Slechts diegene mag slopen die iets beters kan bouwen."
Maar, krijg ik dan niet het zelfde als GetKey() ect. wat windows zelf heeft? (en dan dus ook dat de console nog steeds doet alsof de key's voor de console bestemt waren)
Beware of the Raping Zebra's
Waarschijnlijk zal je de input buffer moeten flushen. Ik heb echter niet direct een idee hoe je dat doet in een console applicatie...
Iets als:
wellicht?
Iets als:
| 1 2 | while((c = getchar()) != '\n' && c != EOF) /* discard */ ; |
tja, voor iets als cin oid zal het wel werken ja maar, niet als je key states wil kunnen bekijken zonder dat je programma gaat wachten op een key input
Beware of the Raping Zebra's
Voor key inputs kun je gewoon een messagehandler aan je console app toevoegen. Geen idee hoe of wat dat met je "na het afsluiten kom ik er achter dat cmd het ook nog registreert en dan dus allemaal andere commando'"-probleem doet.
http://msdn.microsoft.com/en-us/library/ms686016
(werkt alleen op Ramen)
@hierboven: cin.flush() ? - Nee, wacht, schijnt niet te kunnen. cin.sync() dan of cin.ignore()?
http://msdn.microsoft.com/en-us/library/ms686016
(werkt alleen op Ramen)
@hierboven: cin.flush() ? - Nee, wacht, schijnt niet te kunnen. cin.sync() dan of cin.ignore()?
Die SetConsoleCtrlHandler functie waaraan je refereerd is voor het afvangen van system events (Ctrl-C, Uitloggen, etc), niet voor alle toetsen.
Dit voorbeeld van MSDN doet echter wel precies wat je zou willen:
http://msdn.microsoft.com/en-us/library/ms685035(v=VS.85).aspx. Die laat zien hoe je input events van de console leest (toetsen indrukken, toetsen loslaten, mouse events, etc) en afhandled. Doordat je dus key-presses en key-releases krijgt, kun je dus zelf bijhouden welke toetsen ingedrukt zijn.
Volgens mij is die ReadConsoleInput trouwens wel blocking, dus lijkt het me zinvol om dat in een apparte thread te doen.
Maar als je toch Win32 gebaseerde eventhandlers gaat schrijven, waarom maak je dan nog een console applicatie?
Dit voorbeeld van MSDN doet echter wel precies wat je zou willen:
http://msdn.microsoft.com/en-us/library/ms685035(v=VS.85).aspx. Die laat zien hoe je input events van de console leest (toetsen indrukken, toetsen loslaten, mouse events, etc) en afhandled. Doordat je dus key-presses en key-releases krijgt, kun je dus zelf bijhouden welke toetsen ingedrukt zijn.
Volgens mij is die ReadConsoleInput trouwens wel blocking, dus lijkt het me zinvol om dat in een apparte thread te doen.
Maar als je toch Win32 gebaseerde eventhandlers gaat schrijven, waarom maak je dan nog een console applicatie?
oe, txs Ai_KaRaMBa, dr zit ook een muis dinges bij, dat is wel handig eigenlijk 
Ik ga daar even mee klooien
Ik ga daar even mee klooien
Beware of the Raping Zebra's
Het is gelukt hoor met de link van Ai_KaRaMBa heb ik een thread gemaakt die de key-status bekijkt dus dan heeft mijn programma gewoon draaien en kan ik de key's uitlezen wanneer ik wil
met de link van Ai_KaRaMBa heb ik een thread gemaakt die de key-status bekijkt dus dan heeft mijn programma gewoon draaien en kan ik de key's uitlezen wanneer ik wil
Beware of the Raping Zebra's
Ik heb een probleem met class members en 'friend' in een 'friend' functie blijft de compiler zeggen dat de member private is...
en de functie:
Het gaat om het deel myKey->_KEY_PRESSED[...] = true/false
Weet iemand waarom dit niet werkt? de functie draait overigens wel in een aparte thread ik weet niet of dat uit maakt, maar als ik _KEY_PRESSED 'public' maak werkt het wel...
| 1 2 3 4 5 6 7 8 9 10 11 12 | class Key{ void *_HANDLE; bool _KEY_PRESSED[256]; public: Key(); ~Key() throw(); // operators ed moeten nog bool operator[](const unsigned char &n); friend unsigned long WINAPI Threader_Key(void *Data); }; |
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | unsigned long WINAPI Threader_Key(void *Data){ Thread::Key *myKey = reinterpret_cast<Thread::Key*>(Data); // declaraties en error checks hier weggelaten //dispatch the events to the appropriate handler. for(unsigned i=0; i < cNumRead;i++){ switch(irInBuf[i].EventType){ case KEY_EVENT: if(irInBuf[i].Event.KeyEvent.bKeyDown) myKey->_KEY_PRESSED[irInBuf[i].Event.KeyEvent.wVirtualKeyCode] = true; else myKey->_KEY_PRESSED[irInBuf[i].Event.KeyEvent.wVirtualKeyCode] = false; break; } } } } |
Het gaat om het deel myKey->_KEY_PRESSED[...] = true/false
Weet iemand waarom dit niet werkt? de functie draait overigens wel in een aparte thread ik weet niet of dat uit maakt, maar als ik _KEY_PRESSED 'public' maak werkt het wel...
Beware of the Raping Zebra's
lijkt mij dat je _KEY_PRESSED dan ook als 'friend' moet declareren? Zonder aanduiding is het geloof ik standaard "private", en kan dus een friend functie er niet bij
als ik hem protected maak werkt het btw nog steeds niet maar een friend functie zou gewoon toegang moeten hebben tot alle members (dus ook de private) van een class toch?quote:
lijkt mij dat je _KEY_PRESSED dan ook als 'friend' moet declareren? Zonder aanduiding is het geloof ik standaard "private", en kan dus een friend functie er niet bij
Ja, maar _KEY_PRESSED is een member
| 1 | bool _KEY_PRESSED[256]; |
Beware of the Raping Zebra's
Ik heb in het verleden wel eens met Java ( 
) dergelijke problemen gehad, en daar lag het aan dat de member variabelen private waren, en dat protected fucties daar niet bij konden; ik dacht dat dit probleem iets soortgelijks zou zijn 
Ik ben niet echt ervaren met C++, maar na wat googlen lijkt het inderdaad dat wel had moeten werken: in het eerste voorbeeld in http://www.cplusplus.com/doc/tutorial/inheritance/ doen ze precies hetzelfde als jij...
Mogelijk dat je namespace roet in 't eten gooit???
) dergelijke problemen gehad, en daar lag het aan dat de member variabelen private waren, en dat protected fucties daar niet bij konden; ik dacht dat dit probleem iets soortgelijks zou zijn Ik ben niet echt ervaren met C++, maar na wat googlen lijkt het inderdaad dat wel had moeten werken: in het eerste voorbeeld in http://www.cplusplus.com/doc/tutorial/inheritance/ doen ze precies hetzelfde als jij...
Mogelijk dat je namespace roet in 't eten gooit???
Nee, namespace kan het niet zijn omdat in de class staat welke functie gebruik van de private members mag maken en die functie staat niet in een namespace... Zelf denk ik meer dat het misschien te maken heeft dat de functie in een andere thread draait...quote:
Ik heb in het verleden wel eens met Java (
Ik ben niet echt ervaren met C++, maar na wat googlen lijkt het inderdaad dat wel had moeten werken: in het eerste voorbeeld in http://www.cplusplus.com/doc/tutorial/inheritance/ doen ze precies hetzelfde als jij...
Mogelijk dat je namespace roet in 't eten gooit???
Beware of the Raping Zebra's
Dat de code in verschillende threads draait, zou voor de compiler geen verschil moeten maken. Ik denk dat je probleem toch door de namespaces komt. Je zei dat Threader_Key in de globale namespace staat? Forceer dat dan eens in je code door de friends declaratie zo te schrijven:
Hiertoe moet de functie wel eerst gedeclareerd zijn, geen probleem lijkt me. Ik denk dat dit de compiler-melding oplost.
Als het niet werkt, kan je altijd een access functie á la Key::setKeyPressed(unsigned char idx, bool value) inline definieren, dit zou het probleem ook oplossen en misschien zelfs netter zijn.
| 1 | friend unsigned long WINAPI ::Threader_Key(void *Data); |
Hiertoe moet de functie wel eerst gedeclareerd zijn, geen probleem lijkt me. Ik denk dat dit de compiler-melding oplost.
Als het niet werkt, kan je altijd een access functie á la Key::setKeyPressed(unsigned char idx, bool value) inline definieren, dit zou het probleem ook oplossen en misschien zelfs netter zijn.
"Slechts diegene mag slopen die iets beters kan bouwen."
het forceren met :: heb ik geprobeerd maar zegt ie dood leuk dat ik hem in :: moet declareren...quote:
Dat de code in verschillende threads draait, zou voor de compiler geen verschil moeten maken. Ik denk dat je probleem toch door de namespaces komt. Je zei dat Threader_Key in de globale namespace staat? Forceer dat dan eens in je code door de friends declaratie zo te schrijven:
[ code verwijderd ]
Hiertoe moet de functie wel eerst gedeclareerd zijn, geen probleem lijkt me. Ik denk dat dit de compiler-melding oplost.
Als het niet werkt, kan je altijd een access functie á la Key::setKeyPressed(unsigned char idx, bool value) inline definieren, dit zou het probleem ook oplossen en misschien zelfs netter zijn.
Wat dus niet kan omdat ie in een apart .cpp bestand staat. Maar die oplossing van jou is idd wel netter (had ik nog niet aan gedacht) dus dan pas ik dat gewoon toe en is het probleem ook opgelost.
Bedankt, jij ook Ai_KaRaMBa voor het mee denken
Beware of the Raping Zebra's
