2 threads concurrent uitvoeren

[dominicr]

Hallo

Als in makkelijker gezegd dan gedaan, het volgende probleem:

Ik probeer toetsinvoer dynamisch uit te lezen, dus niet met zaken als cin enz (waarbij je nog op enter oid moet drukken) maar via tcgetattr.

Werkt opzich leuk, alleen ik wil graag als er 2 toetsen ingedrukt zijn, deze om en om laten tonen.

Ik dacht aan de volgende code

code:

pthread_mutex_t countMutex;
Input invoer;
Input invoer2;

 void *speler1(void *threadid)
{


    while(true)
    {   
        //pthread_mutex_lock(&countMutex);
        if( invoer.getKey() == 'w')
        {
            cout   <<  "Key w ingedrukt" << endl;

        }
        if( invoer.getKey() == 's')
        {
            cout  << "Key s ingedrukt" << endl;     
        }       
        //pthread_mutex_unlock(&countMutex);
    }  
  
 
}


void *speler2(void *threadid)
{
    while(true)
    {   
        //pthread_mutex_lock(&countMutex);
        if( invoer2.getKey() == 'i')
        {
            cout   <<  "Key i ingedrukt" << endl;

        }
        if( invoer2.getKey() == 'k')
        {
            cout  << "Key k ingedrukt" << endl;     
        }   
        //pthread_mutex_unlock(&countMutex);
    }  
  
    
}


int main (int argc, char *argv[])
{
   pthread_t thread1, thread2;
   long t = 5;

    pthread_create(&thread1, NULL, speler1, (void *)t); 
  pthread_create(&thread2, NULL, speler2, (void *)t); 

   pthread_exit(NULL);

}

Deze werkt echter niet helemaal goed, toetsaanslagen worden maar 1 op de 4/5 keer verwerkt.

Is deze oplossing wel goed ? of is misschien een vorm van een queue beter ?

Groet

[bobo1on1]

Ik heb zo'n idee dat de input class ergens van leest wat niet thread safe is.

[Anoniem: 294759]

TS, zou je de code tussen [code][/code] statement kunnen zetten?
Dit bevorderd aanzienlijk de leesbaarheid.

[ Voor 45% gewijzigd door Anoniem: 294759 op 01-06-2010 06:47 ]

[Reptile209]

Dit werkt niet.
Je moet naar de KeyDown en KeyUp events gaan luisteren. Zolang je een KeyDown van een toets hebt, maar nog geen KeyUp, wordt 'ie ingedrukt. Je krijgt dan dus (bijvoorbeeld) een KeyDown van w, vervolgens van i, even later een KeyUp van i en nog wat later een KeyUp van w.
Deze events zitten overigens in je mainform, en hoeven niet in aparte threads zoals je nu doet.

[ Voor 17% gewijzigd door Reptile209 op 01-06-2010 07:26 ]

[boe2]

Reptile209 schreef op dinsdag 01 juni 2010 @ 07:04:
Dit werkt niet.
Je moet naar de KeyDown en KeyUp events gaan luisteren. Zolang je een KeyDown van een toets hebt, maar nog geen KeyUp, wordt 'ie ingedrukt. Je krijgt dan dus (bijvoorbeeld) een KeyDown van w, vervolgens van i, even later een KeyUp van i en nog wat later een KeyUp van w.
Deze events zitten overigens in je mainform, en hoeven niet in aparte threads zoals je nu doet.

Het weinige dat ik van gameproductie afweet is dat je juist NIET eventbased moet werken met input omdat het veel te traag en onbetrouwbaar is. Dominicr zijn code zou toch vrij betrouwbaar moeten zijn.

(en mainform? Ik zie nergens een indicatie dat er forms aanwezig zijn)

[ Voor 8% gewijzigd door boe2 op 01-06-2010 09:07 ]

[Anoniem: 47102]

Als je "om-en-om" de toetsen wilt interpreteren, kan je dan niet veel beter dit gewoon 1 thread maken? Het is in dit geval erg kunstmatig om de invoer in twee threads te duwen. Je kan wel de parsing van de toetsen in twee threads (speler1 en speler2) stoppen, terwijl je de input (read_keyboard) in een derde thread stopt. Werk dan met een queue o.i.d. voor de link tussen spelerX en read_keyboard.

[dominicr]

Probleem is meer dat het tegelijkertijd moet, ik krijg maar 1 kbcode door, ookal druk je 2 toetsen tegelijk in.

Deze code had ik gevonden op het internet:

code:

struct termios oldt,  newt;
  int            ch;

  tcgetattr( STDIN_FILENO, &oldt );
  newt = oldt;
  newt.c_lflag &= ~( ICANON | ECHO );
  tcsetattr( STDIN_FILENO, TCSANOW, &newt );
  ch = getchar();
  tcsetattr( STDIN_FILENO, TCSANOW, &oldt );
  return ch;

Volgens mij kijkt dit naar een F0, vervolgens naar de kbcode (die elke 100 ms krijgt) en daarna de release code

Ik zou met enkel de release code kunnen werken, maar ik wil liever dat als ik bv 'w' en 'i' indruk, dat ik dan om en om w & i zie

[Anoniem: 47102]

dominicr schreef op dinsdag 01 juni 2010 @ 09:54:
[...]
Ik zou met enkel de release code kunnen werken, maar ik wil liever dat als ik bv 'w' en 'i' indruk, dat ik dan om en om w & i zie

Zodra je dus een w-down waarneemt zet je de 'w' flag op true, bij een w-up zet je hem weer op false.
Daarmee kan je dus gewoon controleren of de toets is ingedrukt a.d.v. een variabele.
In een andere thread zorg je dat er dan een 'w' afhandeling wordt gedaan.Ofwel met timers, ofwel met een sequentiele code, maar niet met threads en mutexes. De laatste is namelijk een oplossing voor een probleem dat er niet is.

[Anoniem: 14027]

Boeboe schreef op dinsdag 01 juni 2010 @ 09:04:
[...]


Het weinige dat ik van gameproductie afweet is dat je juist NIET eventbased moet werken met input omdat het veel te traag en onbetrouwbaar is. Dominicr zijn code zou toch vrij betrouwbaar moeten zijn.

(en mainform? Ik zie nergens een indicatie dat er forms aanwezig zijn)

Niks mis met event-based afvangen van keyboard input in games hoor. Waar haal je vandaan dat het traag of onbetrouwbaar zou zijn?

[Hydra]

Anoniem: 14027 schreef op dinsdag 01 juni 2010 @ 11:51:
Niks mis met event-based afvangen van keyboard input in games hoor. Waar haal je vandaan dat het traag of onbetrouwbaar zou zijn?

In het geval van een FPS bijvoorbeeld werkt dat gewoon niet. Je bent dan afhankelijk van de event snelheid van toetsen. Druk en houdt je A toets maar eens in, op je scherm krijg je een A, dan een pauze, en dan met een bepaalde regelmaat de rest van de A's. Dat is het tempo waar je die events ook mee gaat krijgen.

Event e.d. zijn vooral bedoeld voor forms applicaties. Voor een FPS zul je zelf de keyboard states moeten gaan pollen in je game loop.

[Anoniem: 47102]

Hydra schreef op dinsdag 01 juni 2010 @ 14:00:
[...]


In het geval van een FPS bijvoorbeeld werkt dat gewoon niet. Je bent dan afhankelijk van de event snelheid van toetsen. Druk en houdt je A toets maar eens in, op je scherm krijg je een A, dan een pauze, en dan met een bepaalde regelmaat de rest van de A's. Dat is het tempo waar je die events ook mee gaat krijgen.

Event e.d. zijn vooral bedoeld voor forms applicaties. Voor een FPS zul je zelf de keyboard states moeten gaan pollen in je game loop.

Ja, niet dus he. Windows heeft simpelweg een key-repeat optie erin zitten, dat is niet de snelheid waarmee events zich door het systeem verplaatsen, dat is de snelheid die de timer voor key-repeat heeft.
Alle spellen tegenwoordig gebruiken net zo goed threads en events om dergelijke zaken af te handelen, maar in plaats van dat ze de window key repeat functie gebruiken, gebruiken ze de daadwerkelijke keyboard events. Die weer gekoppeld zijn aan andere threads om de toestand van het toetsenbord af te handelen.

Het pollen van een toetsenbord in een spel is zoooo 1995!

[leuk_he]

sdl:

http://lazyfoo.net/SDL_tutorials/lesson10/index.php

[matthijsln]

Anoniem: 47102 schreef op dinsdag 01 juni 2010 @ 14:25:
[...]
Het pollen van een toetsenbord in een spel is zoooo 1995!

Wat hij beschrijft (zoals het SDL voorbeeld) is anders niet fundamenteel anders hoor.

1995: keyboard interrupt -> change key state variabele

2010: ontvang message in message loop -> change key state variabele

1995 en 2010: main loop: check ("poll" is niet echt een goede benaming) key state variabelen

Met threads maak je het alleen maar complexer.