Skrivet av iXam:
Måste man anpassa projektet något för att kompilera om den eller är det magi som bara fungerar rakt av?
I mitt fall utgick jag ifrån min linux-port, och bland det första jag fick ändra på där var att stega bak till glfw2 hellre än glfw3. Detta för att glfw är något som inte kan bara fungera av magi, någon måste mappa tex mouse events som tricklar ner i DOMen till de event jag sen pollar för när jag använder biblioteket. Lyckligtvis har några redan gjort det jobbet, och man får det med Emscripten, men endast för glfw2 än så länge. Men ja, använder man sig bara av något som stödjs av Emscripten, även något med lite klurigare sidoeffekteer som glfw, då fungerar det bara rakt av. Vidare fick jag dra in en egen version av zlib (som libpng beror på) och kompilera det själv, för det var något jag tidigare berodde på att det fanns tillgängligt i den toolchain man använde. Konstigt nog får man med en header fil för zlib i Emscripten men nej inte resten.. Jag kan ha missat något där.
Det större problemet jag hade var att mitt projekt är multitrådat. Tre trådar, specifikt, (render, main och UI) alla med varsin main loop. Och problemet där är att browsers inte tycker om main loopar i javascript. (javascript måste avsluta sin exekvering) Det jag funderade först på var om jag kunde använda web workers, men även de verkar ganska begränsade. Det går säkert, men skulle vara bra mycket mer jobb. Det jag gjorde istället var att halvt hacka in stöd för att bygga det hela som ett singel-trådat program, vilket gick rätt bra uppenbarligen. Då kunde jag säga till Emscripten att "här är min main loop", sen kunde min (UI) main loop kalla på nästa main loop som kallar på nästa main loop..
Sen stötte jag även in i två mindre men ganska intressanta problem. Det första var att jag hade varit oförsiktig med type casting på ett ställe, som resulterade i läckt minne. Där var det egentligen em++ (C++ kompilatorn i Emscripten) som skälde på mig, något om att den inte viste hur den skulle delete'a min void-pekare. Där var det så enkelt som att Emscripten använder libc++ hellre än libstdc++ som jag använt tidigare för både linux och android. I den implementationen av standard biblioteken hade de helt enkelt varit bättre på att varna för egentligen uppenbara fel. Det andra mindre men intressanta problemet var att jag använde mig av oinitialiserat minne på ett ställe under startup. Jag har inte undersökt det helt och hållet men jag fick åtminstonde inga symptom av det när jag körde på linux eller android.
Annars handlar det egentligen mest om att anpassa ens byggsystem för att använda just Emscripten. Jag tex använder GYP som inte riktigt var ämnat för det, så det gick inte helt smidigt och jag har några hack för att få det att hänga ihop. Allt som allt var det ett relativt smärtfritt två-kvällars-jobb. Du kan se allt som behövdes göras (och lite därtill) i de 3 och 8 sista commitsen på hobo respektive nanaka.
