{"id":1440,"date":"2018-08-05T07:39:13","date_gmt":"2018-08-05T07:39:13","guid":{"rendered":"http:\/\/demensdeum.com\/blog\/?p=1440"},"modified":"2025-08-12T12:05:33","modified_gmt":"2025-08-12T09:05:33","slug":"black-screen-opengl","status":"publish","type":"post","link":"https:\/\/demensdeum.com\/blog\/pt\/2018\/08\/05\/black-screen-opengl\/","title":{"rendered":"Vencemos Malevich, Black Squares OpenGl"},"content":{"rendered":"<p> Malevich chega periodicamente a qualquer desenvolvedor no OpenGL. Isso acontece inesperadamente e com ousadia, voc\u00ea apenas inicia o projeto e v\u00ea um quadrado preto em vez de uma renderiza\u00e7\u00e3o maravilhosa: <\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1441\" src=\"https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/malevich.png\" alt=\"\" width=\"688\" height=\"553\" srcset=\"https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/malevich.png 688w, https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/malevich-300x241.png 300w\" sizes=\"auto, (max-width: 688px) 100vw, 688px\" \/><\/p>\n<p> Hoje descreverei por que motivo fui visitado por um quadrado preto, os problemas encontrados por causa dos quais o OpenGL n\u00e3o desenha nada na tela e \u00e0s vezes at\u00e9 torna a janela transparente. <\/p>\n<p><H3> Use ferramentas <\/h3>\n<p> Para depurar o OpenGL, duas ferramentas me ajudaram: <a href = \"https:\/\/github.com\/baldurk\/renderdoc\" Target = \"_ Blank\" rel = \"Noopener\"> renderdoc <\/apitr e <aa> e <a href = \"https:\/\/github.com\/apitrace\/apitrace\/aprace> e&#8221; https:\/\/github.com\/apitrace\/apitrace> e &#8220;https:\/\/github.com\/apitrace\/aptrace\/apitrace> e&#8221; https &#8220;\/\/github.com\/apitrace\/aptrace &#8220;e&#8221; https &#8220;\/&#8221; &#8220;\/APTRACT\/APTRACE &#8220;e&#8221; https &#8220;> _bithub.com\/apitrace\/&#8221; Apitrace <\/a>. Renderdoc &#8211; ferramenta para depurar o processo de renderiza\u00e7\u00e3o do OpenGL, voc\u00ea pode visualizar tudo &#8211; V\u00e9rtices, shaders, texturas, mensagens de d\u00edvida do motorista. Apitrace &#8211; Uma ferramenta para rastrear desafios de uma API gr\u00e1fica faz chamadas de despejo e mostra argumentos. H\u00e1 tamb\u00e9m uma grande oportunidade de comparar dois lix\u00f5es via Wdiff (ou sem, mas n\u00e3o t\u00e3o conveniente) <\/p>\n<p><H3> Verifique com quem voc\u00ea trabalha <\/h3>\n<p> Eu tenho um sistema operacional Ubuntu 16.10 com depend\u00eancias antigas SDL2, GLM, Assimp, Glew. Na vers\u00e3o mais recente do Ubuntu 18.04, recebo a Assembl\u00e9ia do jogo <a href = \"https:\/\/gitlab.com\/demensdeum\/death-mask\" Target = \"_ Blank\" Rel = \"Noopener\"> Death-Mask <\/a> O que n\u00e3o mostra nada na tela (apenas um quadrado). Ao usar chroot e montagem em 16.10 i <strong> recebo uma assembl\u00e9ia de trabalho do jogo com gr\u00e1ficos <\/strong>. <\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1446\" src=\"https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/NOTSUREIF.jpg\" alt=\"\" width=\"417\" height=\"234\" \/><\/p>\n<p>Parece que algo quebrou no Ubuntu 18.04 <\/p>\n<p> <strong> ldd <\/strong> mostrou a linkka \u00e0s bibliotecas id\u00eanticas sdl2, gl. Dirigindo uma constru\u00e7\u00e3o n\u00e3o trabalhadora no RenderDoc, vi lixo na entrada do shader do v\u00e9rtice, mas precisava de uma confirma\u00e7\u00e3o mais s\u00f3lida. Para entender a diferen\u00e7a entre os binarticos, eu os dirigi atrav\u00e9s do <strong> Apitrace <\/strong>. A compara\u00e7\u00e3o de lixeiras me mostrou que a assembl\u00e9ia em uma nova ubunta quebra o programa das perspectivas no OpenGL, na verdade enviando lixo l\u00e1: <\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-1448\" src=\"https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/apicalls.png\" alt=\"\" width=\"1902\" height=\"234\" srcset=\"https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/apicalls.png 1902w, https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/apicalls-300x37.png 300w, https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/apicalls-768x94.png 768w, https:\/\/demensdeum.com\/blog\/wp-content\/uploads\/2018\/08\/apicalls-1024x126.png 1024w\" sizes=\"auto, (max-width: 1902px) 100vw, 1902px\" \/><\/p>\n<p> Matrizes se re\u00fanem na biblioteca GLM. Depois de copiar o GLM de 16.04 &#8211; Recebi a constru\u00e7\u00e3o do jogo novamente. O problema foi a diferen\u00e7a na inicializa\u00e7\u00e3o de uma \u00fanica matriz no GLM 9.9.0, \u00e9 necess\u00e1rio indicar claramente o argumento MAT4 (1.0F) nele no construtor. Tendo mudado a inicializa\u00e7\u00e3o e <a href = \"https:\/\/github.com\/g-truc\/glm\/issues\/797\" rel = \"Noopener\" Target = \"_ Blank\"> escrevendo <\/a> O autor da biblioteca, eu comecei a fazer <a href = \"htglstps:\/\/gitlab.commdum\/MEMMDUMUMUMMUMUMUMUMUMUMUMUMUMUMUMUMUMUMUMUMUMO =\" \"Noopener\"> testes para fsgl <\/a>. No processo de escrita que encontrei falhas no FSGL, as descrevo ainda mais. <\/p>\n<p><H3> Determine quem est\u00e1 na vida <\/h3>\n<p> Para o trabalho correto com o OpenGL, voc\u00ea precisa <strong> <em> voluntariamente \u00e0 for\u00e7a <\/em> <\/strong> solicitar o contexto de uma determinada vers\u00e3o. Ent\u00e3o, ele procura SDL2 (voc\u00ea precisa colocar a vers\u00e3o estritamente antes de inicializar o contexto): <\/p>\n<p> <!-html gerado usando hilite.me-> <\/p>\n<p><Div style = \"Antecedentes: #ffffffflafflow: autom\u00e1tico; largura: auto; borda: cinza s\u00f3lido; largura de borda: .1em .1em .1em .8em; preenchimento: .2em .6em;\"><br \/>\n<Pre style = \"margem: 0; altura da linha: 125%;\"> sdl_gl_seettrtribute (sdl_gl_context_major_version, <span style = \"cor: #0000dd; font-weight: Bold;\"> 3 <\/span>);<br \/>\nSdl_gl_settribute (sdl_gl_context_minor_version, <span style = \"color: #0000dd; font-weight;\"> 2 <\/span>);<br \/>\nSdl_gl_settribute (SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE);\n<\/pre>\n<\/div>\n<p> Por exemplo, o renderDoc n\u00e3o funciona com contextos abaixo de 3.2. Gostaria de observar que, depois de alternar o contexto <strong>, h\u00e1 uma alta probabilidade de ver a mesma tela preta <\/strong>. Por que? <Br \/><br \/>\nComo o contexto <strong> do OpenGL 3.2 deve exigir a presen\u00e7a de buffer VAO <\/strong>, sem o qual 99% dos drivers gr\u00e1ficos n\u00e3o funcionam. Adicione f\u00e1cil: <r \/><br \/>\n<!-html gerado usando hilite.me-> <\/p>\n<p><Div style = \"Antecedentes: #ffffffflafflow: autom\u00e1tico; largura: auto; borda: cinza s\u00f3lido; largura de borda: .1em .1em .1em .8em; preenchimento: .2em .6em;\"><br \/>\n<Pre style = \"margem: 0; altura da linha: 125%;\"> glgenvertexarrays (<span style = \"cor: #0000dd; font-weight: BOLD;\"> 1 <\/span>, <span style = \"cor. #333333;\"> &#038; <\/span> vao);<br \/>\nGlbindvertexaray (VAO);\n<\/pre>\n<\/div>\n<p><H3> N\u00e3o durma, congele <\/h3>\n<p> Tamb\u00e9m encontrei um problema interessante no Kubuntu, em vez de um quadrado preto, fui exibido transparente e, \u00e0s vezes, <\/strong> tudo era renderizado corretamente. Encontrei a solu\u00e7\u00e3o para esse problema no Stack Overflow: <r \/><br \/>\n<a href=\"https:\/\/stackoverflow.com\/questions\/38411515\/sdl2-opengl-window-appears-semi-transparent-sometimes\" target=\"_blank\" rel=\"noopener\">https:\/\/stackoverflow.com\/questions\/38411515\/sdl2-opengl-window-appears-semi-transparent-sometimes<\/a><\/p>\n<p> O c\u00f3digo de renderiza\u00e7\u00e3o do teste FSGL tamb\u00e9m estava presente <strong> Sleep (2s) <\/strong>; Ent\u00e3o, no Xubuntu e Ubuntu, recebi a renderiza\u00e7\u00e3o correta e enviei o pedido para dormir, mas no Kubuntu recebi uma tela transparente em 80% do lan\u00e7amento do golfinho e 30% dos lan\u00e7amentos e terminais. Para resolver esse problema, adicionei a renderiza\u00e7\u00e3o em cada quadro, ap\u00f3s uma pesquisa do SDLEVENT, conforme recomendado na documenta\u00e7\u00e3o. <\/p>\n<p> C\u00f3digo de teste: <r \/><br \/>\n<a href=\"https:\/\/gitlab.com\/demensdeum\/FSGLtests\/blob\/master\/renderModelTest\/\" target=\"_blank\" rel=\"noopener\">https:\/\/gitlab.com\/demensdeum\/FSGLtests\/blob\/master\/renderModelTest\/<\/a><\/p>\n<p><H3> Fale com o motorista <\/h3>\n<p> OpenGL suporta o canal de comunica\u00e7\u00e3o entre o aplicativo e o driver, para ativ\u00e1-lo, voc\u00ea precisa ativar os sinalizadores GL_DEBUG_OUTPUT, GL_DEBUG_OUTPUT_SYNCHRONUS, Afixar o aviso <span Class = \"PL-C1\"> GLDebugMessagEntrol <\/span> e tie the callback atrav\u00e9s de <nPalback \" <\/Span>. <br \/>\nUm exemplo de inicializa\u00e7\u00e3o pode ser tomado aqui: <r \/><br \/>\n<a href=\"https:\/\/github.com\/rock-core\/gui-vizkit3d\/blob\/master\/src\/EnableGLDebugOperation.cpp\" target=\"_blank\" rel=\"noopener\">https:\/\/github.com\/rock-core\/gui-vizkit3d\/blob\/master\/src\/EnableGLDebugOperation.cpp<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Malevich chega periodicamente a qualquer desenvolvedor no OpenGL. Isso acontece inesperadamente e com ousadia, voc\u00ea apenas inicia o projeto e v\u00ea um quadrado preto em vez de uma renderiza\u00e7\u00e3o maravilhosa: Hoje descreverei por que motivo fui visitado por um quadrado preto, os problemas encontrados por causa dos quais o OpenGL n\u00e3o desenha nada na tela<a class=\"more-link\" href=\"https:\/\/demensdeum.com\/blog\/pt\/2018\/08\/05\/black-screen-opengl\/\">Continue reading <span class=\"screen-reader-text\">&#8220;Vencemos Malevich, Black Squares OpenGl&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[49,61,52],"tags":[],"class_list":["post-1440","post","type-post","status-publish","format-standard","hentry","category-blog","category-techie","category-tutorials","entry"],"translation":{"provider":"WPGlobus","version":"3.0.2","language":"pt","enabled_languages":["en","ru","zh","de","fr","ja","pt","hi"],"languages":{"en":{"title":true,"content":true,"excerpt":false},"ru":{"title":true,"content":true,"excerpt":false},"zh":{"title":true,"content":true,"excerpt":false},"de":{"title":true,"content":true,"excerpt":false},"fr":{"title":true,"content":true,"excerpt":false},"ja":{"title":true,"content":true,"excerpt":false},"pt":{"title":true,"content":true,"excerpt":false},"hi":{"title":false,"content":false,"excerpt":false}}},"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/posts\/1440","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/comments?post=1440"}],"version-history":[{"count":23,"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/posts\/1440\/revisions"}],"predecessor-version":[{"id":4220,"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/posts\/1440\/revisions\/4220"}],"wp:attachment":[{"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/media?parent=1440"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/categories?post=1440"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/pt\/wp-json\/wp\/v2\/tags?post=1440"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}