> ... by compiling with optimization flag -O3. Uh oh, that doesn't sound right :) If your code has different behaviour between optimized and non-optimized builds I would definitely look into this as early as possible, because any later time will only make debugging much worse. Non-initialized memory (like the initial webgl-attributes issue) are one common reason for such differences, so there's probably uninitialized memory lurking elsewhere too.
On Wednesday, 3 November 2021 at 05:48:27 UTC+1 [email protected] wrote: > Apparently I was able to get past the memory issue by compiling with > optimization flag -O3. > > I will check out that link though, it might help me in the future. > > Thanks! > > On Tuesday, November 2, 2021 at 6:05:15 AM UTC-5 Floh wrote: > >> > However, I get a different (unrelated) error now which is that the >> browser crashes because it runs out of memory... >> >> This sounds like a memory leak, AFAIK memory growth is now enabled by >> default in WASM, so ALLOW_MEMORY_GROWTH is redundant. >> >> Emscripten has various features to aid with memory debugging, this is >> probably a good starting point: >> >> https://web.dev/webassembly-memory-debugging/ >> On Tuesday, 2 November 2021 at 12:00:26 UTC+1 Floh wrote: >> >>> Ah dang, yeah totally makes sense. I guess that's one of those pitfalls >>> in C that are so obvious that one gets blind about. >>> >>> > Of course I have no idea WHY any of this needs to be done. >>> >>> The line: >>> >>> EmscriptenWebGLContextAttributes attrs; >>> >>> ...means that 'attrs' has random memory content (because it's a C >>> struct, not a C++ class with constructor), and the >>> emscripten_webgl_init_context_attributes() call initializes the memory to >>> something sane (probably just clearing the memory to zero). This >>> initialization pattern is fairly common in C APIs, but not in C++ APIs. >>> >>> Cheers! >>> >>> On Tuesday, 2 November 2021 at 08:09:08 UTC+1 [email protected] >>> wrote: >>> >>>> It looks like I have found a solution thanks to someone in the Discord >>>> server. Here is what I changed: >>>> >>>> EmscriptenWebGLContextAttributes attrs; >>>> attrs.antialias = true; >>>> attrs.majorVersion = 3; >>>> attrs.minorVersion = 2; >>>> attrs.alpha = true; >>>> attrs.powerPreference = EM_WEBGL_POWER_PREFERENCE_DEFAULT; >>>> >>>> // The following lines must be done in exact order, or it will >>>> break! >>>> emscripten_webgl_init_context_attributes(&attrs); // you MUST init >>>> the attributes before creating the context >>>> attrs.majorVersion = 3; // you MUST set the version AFTER the above >>>> line >>>> EMSCRIPTEN_WEBGL_CONTEXT_HANDLE webgl_context = >>>> emscripten_webgl_create_context("#canvas", &attrs); >>>> emscripten_webgl_make_context_current(webgl_context); >>>> mainContext = SDL_GL_CreateContext(window); >>>> >>>> When you modify my main.cpp with this code then it actually shows the >>>> game on the screen and all of the above errors I mentioned disappear. So >>>> the solution is to call emscripten_webgl_init_context_attributes between >>>> creating the attributes and before creating the context. However, if you >>>> do >>>> that then it sets up the webgl context using OpenGL ES 2.0 (WebGL 1.0) >>>> which is not what I want (because I would need to change all my shader >>>> code). So that's why you need to set the attributes AGAIN after calling it >>>> (to set majorVersion=3) which results in OpenGL ES 3.0 / WebGL 2.0. >>>> >>>> Of course I have no idea WHY any of this needs to be done. I hope this >>>> can either be fixed or documented somewhere with an explanation. >>>> >>>> I managed to copy and paste this code into my larger game project and >>>> it worked like a charm. However, I get a different (unrelated) error now >>>> which is that the browser crashes because it runs out of memory... but at >>>> least I can see the game now. The preloaded data file is ~80 MB which >>>> isn't >>>> huge by video game standards, but it might be too big for the browser to >>>> download. I did set ALLOW_MEMORY_GROWTH=1 but that didn't seem to prevent >>>> the issue. If anyone can help me out with that too please let me know. >>>> Thanks. >>>> >>>> On Monday, November 1, 2021 at 9:20:16 AM UTC-5 Floh wrote: >>>> >>>>> PS: if you just want to get something on screen in a cross-platform >>>>> application, but don't care if it's SDL2 or GL, check out my sokol >>>>> headers: >>>>> >>>>> https://floooh.github.io/sokol-html5/ >>>>> >>>>> No guarantee that this will protect you from any C++ shenanigans >>>>> though, the headers can be used from C++, but since I prefer plain old C >>>>> these days, most of the sample code is written in C (and the few C++ >>>>> samples - mainly the Dear ImGui stuff - doesn't use the STL). >>>>> On Monday, 1 November 2021 at 15:16:29 UTC+1 Floh wrote: >>>>> >>>>>> I'm also able to reproduce the problem on macOS with Chrome and >>>>>> Safari, but no idea either what's going wrong there. >>>>>> >>>>>> However, I suspect it's not the use of std::string, but that iostream >>>>>> is the culprit, because if I replace std::cout with printf but keep >>>>>> std::string, it works (replacing cout with printf is a good idea anyway, >>>>>> because cout adds an incredible amount of bloat last I checked). >>>>>> >>>>>> On Monday, 1 November 2021 at 12:38:16 UTC+1 [email protected] >>>>>> wrote: >>>>>> >>>>>>> I'm glad someone was able to reproduce it, but that didn't answer >>>>>>> any of my questions. >>>>>>> >>>>>>> I've tried a few more things and maybe the issue is related to >>>>>>> strings in some way. If I add a class that takes a string as a >>>>>>> parameter in >>>>>>> the constructor, and then ONLY if I instantiate it, like so: >>>>>>> >>>>>>> class Test >>>>>>> { >>>>>>> public: >>>>>>> Test(std::string test) {} ; >>>>>>> }; >>>>>>> >>>>>>> int main() >>>>>>> { >>>>>>> Test test("test"); >>>>>>> InitOpenGL(1280, 720, window, mainContext); >>>>>>> BeforeMainLoop(); >>>>>>> >>>>>>> return 1; >>>>>>> } >>>>>>> >>>>>>> Then that also results in a black screen. Instantiating a vector of >>>>>>> strings also results in a black screen, like so: >>>>>>> std::vector<std::string> languages = { "english", "japanese" }; >>>>>>> >>>>>>> And my original problem with the Log function also happens to >>>>>>> involve strings on some level. If I change the constructor from a >>>>>>> string to >>>>>>> a const char* then it works. But changing all instances of strings to >>>>>>> const >>>>>>> char* is not ideal (my program needs strings), and I actually tried >>>>>>> that >>>>>>> with the Log function and that did not help, so I'm still looking for a >>>>>>> solution. So hopefully this information is helpful for someone to >>>>>>> figure >>>>>>> out what is wrong and how to fix it. >>>>>>> >>>>>>> >>>>>>> On Sunday, October 31, 2021 at 12:23:53 AM UTC-5 Shlomi Fish wrote: >>>>>>> >>>>>>>> Hi all! >>>>>>>> >>>>>>>> On Sat, 30 Oct 2021 18:46:19 -0700 (PDT) >>>>>>>> Anton Strickland <[email protected]> wrote: >>>>>>>> >>>>>>>> > I have been stuck on a very simple issue for multiple days and >>>>>>>> need someone >>>>>>>> > who knows what they are doing. I'm trying to use SDL2 and WebGL2 >>>>>>>> (OpenGL ES >>>>>>>> > 3) and sometimes it works, but sometimes it doesn't, depending on >>>>>>>> seemingly >>>>>>>> > arbitrary code. Please help. See here for the full details and >>>>>>>> source code: >>>>>>>> > >>>>>>>> > >>>>>>>> https://gist.github.com/AntonStrickland/433c911151ca73826ee679b120fe8d9e >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> Note that I was able to reproduce the issue on fedora v34 x86-64 >>>>>>>> with firefox: >>>>>>>> >>>>>>>> ``` >>>>>>>> System: >>>>>>>> Host: telaviv1.shlomifish.org Kernel: 5.14.14-200.fc34.x86_64 >>>>>>>> x86_64 >>>>>>>> bits: 64 Desktop: Xfce 4.16.0 Distro: Fedora release 34 (Thirty >>>>>>>> Four) >>>>>>>> CPU: >>>>>>>> Info: Dual Core model: Intel Core i3-2100 bits: 64 type: MT MCP >>>>>>>> cache: >>>>>>>> L2: 3 MiB >>>>>>>> Speed: 2750 MHz min/max: 1600/3100 MHz Core speeds (MHz): 1: 2750 >>>>>>>> 2: 2698 3: 2709 4: 2694 >>>>>>>> Graphics: >>>>>>>> Device-1: Intel 2nd Generation Core Processor Family Integrated >>>>>>>> Graphics >>>>>>>> driver: i915 v: kernel Display: x11 server: X.Org 1.20.11 driver: >>>>>>>> loaded: >>>>>>>> modesetting unloaded: fbdev,vesa resolution: 1920x1080~60Hz >>>>>>>> OpenGL: renderer: Mesa DRI Intel HD Graphics 2000 (SNB GT1) >>>>>>>> v: 3.3 Mesa 21.1.8 >>>>>>>> ``` >>>>>>>> >>>>>>>> As a side note: main.cpp has some trailing whitespace: >>>>>>>> https://perl-begin.org/tutorials/bad-elements/#trailing-whitespace >>>>>>>> >>>>>>>> > Basically, I have a simple program (just over 100 lines of code) >>>>>>>> that >>>>>>>> > changes the background color of the screen by calling glClear(). >>>>>>>> Probably >>>>>>>> > the most basic OpenGL program one can write. When the color is >>>>>>>> pink, that >>>>>>>> > means it's working, and when it's black, it's not working. In the >>>>>>>> above >>>>>>>> > link there is main.cpp which works correctly. I have been doing >>>>>>>> trial and >>>>>>>> > error for this past week commenting out random lines of code to >>>>>>>> isolate the >>>>>>>> > problem, but it seems like changing arbitrary lines of code stops >>>>>>>> it from >>>>>>>> > working. I've noticed that it happens when calling some SDL >>>>>>>> functions, but >>>>>>>> > even just commenting out printing to the console is enough to >>>>>>>> break it. See >>>>>>>> > main.cpp for details. >>>>>>>> > >>>>>>>> > I don't know if this is just an issue with me not understanding >>>>>>>> how this >>>>>>>> > works or if this is an actual bug in emscripten or the SDL port. >>>>>>>> it's >>>>>>>> > frustrating because when it works, it works all the way (I can >>>>>>>> use shaders >>>>>>>> > and textures to have a working app), but if I change just a tiny >>>>>>>> little >>>>>>>> > thing (even just commenting out an unrelated line of code), >>>>>>>> suddenly >>>>>>>> > nothing works at all. I have no idea where to even start >>>>>>>> debugging this. >>>>>>>> > >>>>>>>> > I would imagine that there has to be a way to do this since >>>>>>>> people are >>>>>>>> > obviously making WebGL games in C++, but since there are no >>>>>>>> tutorials >>>>>>>> > online for how to do that it becomes impossible to even set up a >>>>>>>> simple >>>>>>>> > "hello world" script. I purchased a book on how to make games in >>>>>>>> web >>>>>>>> > assembly but they use the SDL renderer and not OpenGL rendering. >>>>>>>> Other >>>>>>>> > OpenGL web assembly tutorials just use OpenGL without SDL. Surely >>>>>>>> there >>>>>>>> > must be a way to use them together as I have done for my desktop >>>>>>>> app? >>>>>>>> > >>>>>>>> > I have already reached out on the discord but to no avail so far. >>>>>>>> Someone >>>>>>>> > suggested adding -fsanitize=address when compiling but that >>>>>>>> actually causes >>>>>>>> > the above working code to stop working. I don't really have the >>>>>>>> time to >>>>>>>> > just wait for an answer so I'm hoping this post will get the >>>>>>>> attention of >>>>>>>> > more people. >>>>>>>> > >>>>>>>> > So I know this is getting long, but I'm very confused. Since >>>>>>>> technically by >>>>>>>> > code works, but it's one step away from breaking, and I have no >>>>>>>> idea what >>>>>>>> > that step is or why. My ultimate goal is to copy and paste this >>>>>>>> code into a >>>>>>>> > larger project, but every time I do so, it results in a black >>>>>>>> screen with >>>>>>>> > no indication of what I did wrong. >>>>>>>> > >>>>>>>> > I would like to understand a few things: >>>>>>>> > >>>>>>>> > - Is this a problem with my code, my makefile, SDL, or >>>>>>>> emscripten? >>>>>>>> > - If this is not a problem with my code, is someone going to fix >>>>>>>> the >>>>>>>> > issue? >>>>>>>> > - If my desktop code is Open GL 3.3, should I be using OpenGL ES >>>>>>>> 3 or is >>>>>>>> > that part of the problem? And what files do I need to include and >>>>>>>> where do >>>>>>>> > I get them (if what I have isn't correct?) >>>>>>>> > - What is the proper way to set up an emscripten webgl context? >>>>>>>> My >>>>>>>> > source code includes two different ways of setting it up and I am >>>>>>>> not sure >>>>>>>> > which is correct, even after trial and error. >>>>>>>> > - Can I get someone who is willing to at least compile the code >>>>>>>> > themselves and try out different solutions until they find >>>>>>>> something that >>>>>>>> > can provide an explanation? I don't want someone to suggest >>>>>>>> adding a >>>>>>>> > single argument to my makefile, and then hours later I get home >>>>>>>> to try it out >>>>>>>> > and realize that it actually causes the program to fail. My >>>>>>>> program is small >>>>>>>> > enough that someone can copy and paste it together, compile it, >>>>>>>> and run it >>>>>>>> > in less than 2 minutes. There is no reason to not do that >>>>>>>> yourself to >>>>>>>> > check that it works before suggesting a solution to me. I am just >>>>>>>> a little >>>>>>>> > frustrated at this point so please don't take it the wrong way, I >>>>>>>> just >>>>>>>> > want someone to take me seriously so I can move on to the next >>>>>>>> step of my >>>>>>>> > project. >>>>>>>> > - If this mailing list is not the best place to quickly get help >>>>>>>> like >>>>>>>> > that, who do I need to contact? I am willing to pay for work if >>>>>>>> that needs >>>>>>>> > to be done, but I don't think that should be necessary to get a >>>>>>>> "hello >>>>>>>> > world" program up and running, especially when I've already come >>>>>>>> this far >>>>>>>> > on my own. >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Shlomi Fish https://www.shlomifish.org/ >>>>>>>> Free (Creative Commons) Music Downloads, Reviews and more - >>>>>>>> https://jamendo.com/ >>>>>>>> >>>>>>>> <LeoNerd> “I hear eclipse is really nice, but I’m still waiting for >>>>>>>> it to >>>>>>>> load.” >>>>>>>> — Freenode’s #perl >>>>>>>> >>>>>>>> Please reply to list if it's a mailing list post - >>>>>>>> https://shlom.in/reply . >>>>>>>> >>>>>>> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/ce416de7-3dbf-43e4-b012-9668be1cc654n%40googlegroups.com.
