Spelontwikkelaars ontdekken eindelijk multicore

Origineel bericht van Onbekend 12/04/2007
Om multicore te ontwikkelen moet je in staat zijn om multi-threaded te schrijven en dat is zeker niet iets voor een beginner met een zwak hart. Veel programma's die nu ontwikkeld steunen nog steeds op de Windows 3.x achtige cooperative multi-tasking technologie want alles draait nog steeds in de main-thread en is veelal message based. Op een splash screen na die in een apparte thread opgestart word of zo.

Het probleem is dat de ontwikkelingstalen niet echt ontwikkeld zijn om multi-threading gemakkelijk te maken. deadlock situaties is niet altijd zo eenvoudig te zien en het is niet altijd duidelijk welke thread welke method oproept.

Een idee zou kunnen zijn is een method dat vanuit meerdere threads kan opgeroepen worden in een ander achtergrondkleur te markeren als de methods die niet worden opgeroepen. Dit in de vorm van intelisens;

Het is nog niet direct vor morgen.

Origineel bericht van interessant 12/04/2007
Deze presentatie is heel interessant: http://lca2007.linux.org.au/talk/252 Vooral het deel waarin verwezen wordt naar games is heel relevant.

Origineel bericht van Onbekend 12/04/2007
Wel Bakoenin, je moet me toch een keer uitleggen hoe jij er in zal slagen om 1 process (= spelleke) te laten draaien op meerdere processoren zonder multi-threading!)

Origineel bericht van Bakoenin 12/04/2007
Hopla, we hebben hier weer nen zakenwasser die een of ander boekje heeft gelezen en hier de forumzot moet komen uithangen. Het beheer van je threads in je code hebben niets te maken met multi processors!!!

Origineel bericht van C er 16/04/2007
Ik kan misschien dom lijken als thread en child programmeur op unix. Maar dit heeft voor mij ten onrechte te maken met de programmeur.
Als programmeur deel ik mijn programma's op in verschillende delen, en qua functionaliteit ook nog in threads waar dit voor mij toegelaten is. Heel sterk vereenvoudigd voorbeeld : beeld en muziek. Na een bepaald event fire ik een geluid en een beeld.
Mij kan het feitelijk niet schelen welke core welk event behandeld.
In tegen deel, ik vraag niet liever dat die zo snel mogelijk onafhankelijk behandeld worden, liefst nog simultaan. Dus als het OS (of SDK/compiler/interpreter) zo slim is om dat te verdelen over de verschillende core's , des te beter.
Mijn Master thread kan het echt niet schelen op welke core wat uitgevoerd wordt.
Nu dit is mijn manier van programmeren, en zeker op unix hebben mijn programma's voordeel uit de multi core.
Heb nog geen port's gedaan naar Windows van deze applicaties.
En bij VB programma's heb ik daar geen vat op. Maar het zelfde principe geld daar kan mij het schelen waar welke methode uitgevoerd wordt.
Ik weet wel dat games met andere engine gemaakt worden, maar ook daar moet dit principe van toepassing blijven.
Ik heb altijd zo gewerkt, ook al was er nog geen sprake van multi core, maar heb duidelijk baat gehad van meerdere core's.
Inter Process communicatie en synchronisation is hier de key.