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/af15c29e-cc47-474c-bbb4-110c7fe2dc31n%40googlegroups.com.

Reply via email to