[C++] [SDL] probleem met threads

[Arjan]

Een goedesmiddags,

Ik heb SDL gekoppeld aan de FFMPEG libs en nu probeer ik de videoframes te updaten in een andere thread, zodat deze op hun eigen snelheid geupdate kunnen worden, volledig onafhankelijk van de main thread.

C++:

int videoThread(void *in);

struct video {
    void getNextFrame();

    void start() {
        SDL_CreateThread(videoThread, this);
    }
};

int videoThread(void *in) {
    video* vid = (video*)in;

    while(ik_vind_dat_je_door_moet_gaan) vid->getNextFrame();

    return 0;
}

int main() {
    video* vid = new video();

    vid->start();

    // op dit punt moet de data wat door getNextFrame wordt geleverd te lezen zijn

    return 0;
}

De thread wordt gewoon uitgevoerd, cout's enzo komen gewoon door, de adressen van de functies ed. zijn hetzelfde als wanneer ik getNextFrame gewoon vanuit main aanroep. Aangezien getNextFrame alleen maar naar private members schrijft zie ik niet hoe hij de data ergens anders heen zou kunnen sturen.

voor de duidelijkheid, de frames die getNextFrame zou moeten wegschrijven zijn helemaal leeg, terwijl ze gewoon gevuld worden als ik de functie aanroep vanuit de main.

alvast heel erg bedankt, want ik kom er niet uit

[ Voor 26% gewijzigd door Arjan op 28-09-2006 13:51 ]

[.oisyn]

Synchronize je wel voordat je een frame probeert uit te lezen? De main thread gaat natuurlijk direct verder na thread->start(), dus die gaat al een frame uitlezen terwijl de nieuwe thread er nog geeneen geproduceerd heeft.

[ Voor 87% gewijzigd door .oisyn op 28-09-2006 13:53 ]

[Arjan]

Ja, ik heb de main niet willen uitschrijven voor duidelijkheid, maar in de main staat op de plaats van een comment een while loop die constant het frame probeert te lezen, deze doet dat echter op een andere snelheid (variabel) vandaar dat ik getNextFrame naar een thread wil afschepen.

saillant detail, onder Linux doet dezelfde code het prima...

[.oisyn]

Dus je synchronizeert niet. Of wil je zeggen dat je een mutex of semaphore object gebruikt om met de ene thread te wachten tot de andere thread z'n data klaar heeft? Zo niet, ga dat eens doen dan

[Arjan]

ok, ik heb semaphores gebruikt, maar zoals ik eigenlijk al verwacht had, maakt dat weinig uit. Ik schrijf naar openGL textures in getNextFrame. Ik gebruik de semaphores om te voorkomen dat de bindtexture call op een ongewenst moment aangeroepen wordt.
de texturen blijven echter nog steeds zwart

[TheNameless]

Kan je misschien wat meer van je code posten?
We kunnen je zo niet verder helpen

[Koetjeboe]

Misschien klopt het niet helemaal wat ik zeg hoor, maar volgens mij waren er wat problemen met opengl en threads, waardoor je eigenlijk al het opengl gebeuren in 1 thread moest stoppen. Je main start nu opengl op denk ik, en deze thread zit er verder mee te prutsen. Maar dit alles was in een beetje beta c# met opengl onder linux achtig test progje.

Heb het zelf ooit opgelost om de dingen die echt opengl aanroepen allemaal in de render thread te gooien, en alleen de informatie wat er nou precies gedaan moet worden te laten veranderen door de andere threads.

Handige site om dit soort info te vinden is natuurlijk gamedev.net, zie bijvoorbeeld http://www.gamedev.net/co...topic.asp?topic_id=122438

[ Voor 6% gewijzigd door Koetjeboe op 28-09-2006 19:37 ]

[Arjan]

Koetjeboe schreef op donderdag 28 september 2006 @ 19:34:
Misschien klopt het niet helemaal wat ik zeg hoor, maar volgens mij waren er wat problemen met opengl en threads, waardoor je eigenlijk al het opengl gebeuren in 1 thread moest stoppen. Je main start nu opengl op denk ik, en deze thread zit er verder mee te prutsen. Maar dit alles was in een beetje beta c# met opengl onder linux achtig test progje.

Heb het zelf ooit opgelost om de dingen die echt opengl aanroepen allemaal in de render thread te gooien, en alleen de informatie wat er nou precies gedaan moet worden te laten veranderen door de andere threads.

Handige site om dit soort info te vinden is natuurlijk gamedev.net, zie bijvoorbeeld http://www.gamedev.net/co...topic.asp?topic_id=122438

aan de hand van wat ik in het topic lees is het inderdaad een windows/opengl related probleem. Erg zonde want nu moet ik de main thread toch weer gaan laten wachten op een ingeladen frame. Ook al is dit dan alleen op die momenten dat de frame-load thread daadwerkelijk een frame aan het laden is, terwijl de main-thread een nieuw frame wil laten zien.