Problem with shader and non-shader graphics
BlitzMax Forums/BlitzMax Programming/Problem with shader and non-shader graphics
| ||
| Hallo ! So I have a module that wants to draw text on the screen using a shader program. DrawText draws stuff on the screen until I use the shader, after which DrawText never outputs anything again on subsequent Flips. However, the shader is always able to draw to the screen. Is there anything in particular I need to reset in order to get GLMax2D to keep rendering after using a shader program? The render section looks like this : glBindTexture( GL_TEXTURE_2D, buf->atlas->id ); glUseProgram( buf->shader ); glUniform1i( glGetUniformLocation( buf->shader, "texture" ), 0 ); glUniformMatrix4fv( glGetUniformLocation( buf->shader, "model" ), 1, 0, buf->model.data); glUniformMatrix4fv( glGetUniformLocation( buf->shader, "view" ), 1, 0, buf->view.data); glUniformMatrix4fv( glGetUniformLocation( buf->shader, "projection" ), 1, 0, buf->projection.data); vertex_buffer_render( buf->buffer, GL_TRIANGLES ); Thanks :-) |
| ||
| What are you working on, Brucey? |
| ||
| Something called FreeType-GL. |
| ||
Textures should be unbound after use. I noticed that was missing from the GL2Max2D module, as well.glBindTexture( GL_TEXTURE_2D, 0 ); |
| ||
| Okay, so the initial version is under source control now : https://github.com/maxmods/bah.mod/tree/master/freetypegl.mod (or via SVN). The example "benchmark" app has been tested and runs on the 3 core platforms. The disappearing DrawText "feature" still exists, and I've no idea what to reset to make it come back. (you'll see what I mean when you press 2 or 3 in the example app). Also note the somewhat improved FPS when running under options 2 and 3. (See console output for values). Linux in particular seems to be very slow with DrawText, whereas on my Mac, the difference between 1 and 2 are not so much. Fonts render slightly differently with this library because it is taking kerning into account. This is most pronounced in the example with "Y.", where the period sits closer to the vertical than it does with DrawText. In theory, rendering should appear more "natural" with this library than with DrawText. |
| ||
| glUseProgram(0) |
| ||
| I assume glUseProgram(0) does what I suggested: it detaches the shader from the program again. (EDIT: I suggested it per mail.) I added your whole post below the two cases in the "benchmark"-example and it displayed the text accordingly. But I must confess: the BlitzMax-DrawText looks a bit more crisp here... the anti-aliasing is a bit "soft" (maybe it is the subpixel aligning of the draw coordinates for the texture). The speed improvements are really huge here on linux (for this static text): 60fps "blitzmax" 420fps "freetypegl draw" 1900fps "freetypegl cache draw" Of course "cache" could be done with vanilla blitzmax too (rendering the glyphs to a TImage and then drawing the image) but that "rendering" would be done using writepixel ... which does not make it that realtime-fancy. bye Ron |
| ||
| Hello. According to the specification, you only need to retrieve the uniform locations after the shader program is linked, so you can store the locations in variables and just reuse them. https://www.opengl.org/sdk/docs/man/docbook4/xhtml/glGetUniformLocation.xml When the next link command occurs, all uniform locations are modified and need to be queried again. You can facilitate this by making use of a hook like "updateUniformLocations," that you run inside the linking method and that every shader program class is hooked to. |
| ||
| glUseProgram(0) Thanks :-) |
| ||
| Supertip: Add 1.0 / (context width or height) * 0.5 to your vertex coords to get pixel-perfect drawing on 2D objects. |
| ||
| Could you explain your supertip? 1.0 / contextDimension = factor for 1 pixel so when adding half of this value you move the pixel position to the next subpixel, or maybe you have luck and it hits a real "integer pixel" position. Without "ceiling/flooring" this should not help... so what is missing in my thought? Another thing: while "Pixel perfect" is possible for the left,top and right,bottom areas (the borders), you cannot achieve this for pixel data on the texture. The freetypegl-module does exactly this: it draws the glyphs on a texture. So the plain texture already contains "smoothed glyphs" (subpixel-positioned). To avoid this, each glyph should "beautify" its own texture position). Hinting alone isn't enough. Modern desktops (Windows, Gnome, ...) do more than just relying on the hinting-information. PLEASE do not read the above as solely critics... it is a fantastic opportunity for text-heavy applications ... so there is no need to cache the text anylonger (I cache tooltips, datasheets, ... as it shapes off some fps). So your supertip is more of interest for image/sprite-drawing. That freetypgl-thing IS one of these sprites/images. EDIT2: Just had another look at the output of freetypegl. Brucey mentioned the hinting (the dot after Y -> "Y."). Maybe one should have a look at the last line containing "royal" - dunno if the hinting is broken there - or if the algorithm does something fancy, but for me it almost looks like "roy al" - with a thinspace-unicode-character inbetween). But like said... critics on a high level. bye Ron |
| ||
| If there were a fast grabimage, caching would become trivial. |
| ||
| Instead of transfering the "screen content" you better would have access to some kind of virtual canvas ... so at the end you would not draw everything to your screens canvas but to another canvas - and THIS is then drawn to the screen canvas. Think you could call this "render to texture". bye Ron |
| ||
| Ahh I see. I actually did that for pixeldoubling on the game I wrote in Monkey but I hadn't considered doing something likewise for fast grabimage. |
   |