Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 39

Thread: OpenGL GLSL - Text rendering query

  1. #11
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,205
    Blog Entries
    2
    So my code does do a two pass at present and providing I use glColor4f(1.0,1.0,1.0,1.0); aka Opaque white, the blend works and the alpha is taken into account from the font texture. And everything is great, but when I change the color to say yellow, the blend changes the colour of the background quad. This is why I was looking at shaders.

    Fundamentally I've been able to write a fragment shader to set the colour to a fixed value, but where I'm coming unstuck is if I use a vertex shader to extract the color (which I understand to be an interpolated value, along with the position information), I'm in a position where it breaks the 2D orthographic projection and nothing I've tried has worked. And I've tried quite a few variations of shader.
    :: AthenaOfDelphi :: My Blog :: My Software ::

  2. #12
    You should not use blend, you should use alpha test.

    Code:
      glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
          glEnable(GL_ALPHA_TEST);
          glAlphaFunc(GL_GREATER, 0.01);
    For shaders... I am beginner myself, but look at my FFP emulation for my GUI:
    (please note that I calculate matrix by hand for GLES compatibility where glRotate() and the like do not exist: these are deprecated)

    Code:
    #version 120
    
    uniform mat4 u_matrix;
    
    attribute vec3 a_position;
    attribute vec4 a_color;
    attribute vec2 a_texCoord;
    
    varying vec2 v_texCoord;
    varying vec4 v_color;
    				
    void main()
    {
    	gl_Position = u_matrix * vec4(a_position[0], a_position[1], a_position[2], 1.0); 
    	v_texCoord = a_texCoord;
    	v_color = a_color;
    }
    Code:
    #version 120
    
    uniform sampler2D u_texture;
    
    varying vec2 v_texCoord;
    varying vec4 v_color;
    
    void main()
    {
    	vec4 mytexel = texture2D( u_texture, v_texCoord);
    	if (mytexel[3] < 0.05) {
    		discard;
    	} else {
    		gl_FragColor = v_color * mytexel;
    	}
    }

  3. #13
    Quote Originally Posted by AthenaOfDelphi View Post
    I thought by having the font in white I could colorise it using glColor prior to my glBegin(GL_QUAD) glVertex..... etc. that binds the glyph in the font texture to the four vertices. Unfortunately this changes the color of the fill behind it, so as I understand it, I need to use shaders to achieve what I want but I'm struggling.
    Try calling the following before your rendering loop:

    glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
    Quote Originally Posted by Chebmaster View Post
    DON'T.
    I beg you, stop and rethink your strategy.
    Any code that has glBegin/glVertex/etc. in it will be doomed to the compatibility ghetto, limited to 20k vertices while any semi-modern hardware is capable of millions.
    This is a really bad advice. See this: Nvidia: Deprecation Myths. Of course everything pre-GL3 is considered legacy now, but it doesn't mean you can't use it for learning. Newer APIs such as Metal/Vulkan/Direct3D 12 are notoriously difficult to get started, so if you want to get something working quickly, glBegin/glEnd is as good as any other option, and in regards in performance, it is likely faster than the source code you suggested (and I challenge you to prove different: do the benchmarks!)

    I would suggest to use whatever technique you find easier to learn - it is better to have something working in the way you want, than not having anything at all.

  4. #14
    This is a really bad advice. See this: Nvidia: Deprecation Myths.
    You are wrong.
    I was not talking about "below 3.3". I was talking about "certain techniques below 2".

    OpenGL 2.1 is *ancient* now - but it's what you should use for learning.
    OpenGL *below* 2, though... It's not just deprecated, it's not just "left to rot" -- you will have to relearn *everything* you learned because those legacy-squared techniques do not scale.

    I performed benchmarking myself and I found that glBegin-style code begins to lag at about 20 000 vertices. That's how badly "left to rot" it is. That's how inefficiently it is emulated.

    So, you learn this, you acquire really bad habits learning it you may even begin making libraries for future use... and then you will have to relearn 50%. You will have to scrap your libraries or salvage what you could of them them using really ugly hacks. You will have to fight your bad habits.

    I've been there. I've done that. I speak from experience.
    It cost me months of my free time.
    I become sad when I see people walking unawares into the same trap.

    P.S. The glBegin technique grew outdated in 20th century, between Quake 2 and Quake 3. If you look at Open Arena sources you will see just half a dozen places where glBegin is used and the vast majority of them are for rendering a single fullscreen quad.
    Long before Crysis. Long before Oblivion. Carmack saw them unfit in 1999.
    Nuff said.

    and I challenge you to prove different: do the benchmarks!
    I definitely will (I'm curious myself how much better my new class is) but it may take weeks: my game engine is currently down for rehauling.
    I can only say that when my subdivided rotating sphere was still working, the difference between glBegin and the new class was difference between SwapBuffers taking most of the allotted frame time and taking a silver of it (intel HD3000)
    Last edited by Chebmaster; 20-01-2018 at 05:58 PM.

  5. #15
    Quote Originally Posted by Chebmaster View Post
    You are wrong.
    I was not talking about "below 3.3". I was talking about "certain techniques below 2".
    Sure, let's pretend you didn't see the link I've posted, or let's pretend that Mark J. Kilgard, the principal engineer in Nvidia responsible of OpenGL driver development, is also wrong - you surely know better, don't you?

    Quote Originally Posted by Chebmaster View Post
    I performed benchmarking myself and I found that glBegin-style code begins to lag at about 20 000 vertices. That's how badly "left to rot" it is. That's how inefficiently it is emulated.
    I would like to see these benchmarks. On most desktop hardware we've done testing happens actually the opposite - glBegin/glEnd is close to performance to glDrawArrays with system pointers (similar to DrawPrimitiveUP in D3D9). When using OpenGL 4.5 features, including DSA, glMapNamedBufferRange (or glNamedBufferSubData) with immutable storage and GL_MAP_INVALIDATE_BUFFER_BIT, supplying vertex data for streaming each frame, it is difficult to get close to performance of the "legacy features" - in fact, we could only achieve better performance by using multiple buffers of gradually increasing sizes and other things like circular buffers with GL_MAP_PERSISTENT_BIT and otherwise AZDO-like features.

    So sure, this is very much legacy, but as long as it is supported and works, if you don't want to learn shaders or any third-party libraries, this is the quickiest way to render something in 3D. Pencil and paper are also very ancient and you can argue that with your new shiny iPad you never need to learn how to hand-write anymore, just until you drop the damn thing on a hard floor or your batteries run out...

  6. #16
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,205
    Blog Entries
    2
    And, in the end, I've just found out what I was doing wrong

    So this code works

    Code:
      glClearColor(0,0,0,1.0);
      glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
      glViewport(0,0,fRenderWidth,fRenderHeight);
      glLoadIdentity;
      gluOrtho2D(0,fRenderWidth,fRenderHeight,0);
      glEnable(GL_TEXTURE_2D);
      glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
      glBindTexture(GL_TEXTURE_2D,fCharacterSets[0].texture);
    
      for y:=0 to 15 do //5 do
      begin
        ty:=y*24;
        for x:=0 to 15 do //5 do
        begin
          tx:=x*24;
    
          idx:=x+(Y*16);
    
          glDisable(GL_BLEND);
    
          glBegin(GL_QUADS);
            glColor4f(fGLPaletteColors[0][idx,0],fGLPaletteColors[0][idx,1],fGLPaletteColors[0][idx,2],1.0);
            glVertex2i(tx,ty);
            glVertex2i(tx+16,ty);
            glVertex2i(tx+16,ty+16);
            glVertex2i(tx,ty+16);
          glEnd;
    
          // Render the font
          glColor4f(fGLPaletteColors[0][255-idx,0],fGLPaletteColors[0][255-idx,1],fGLPaletteColors[0][255-idx,2],1.0);
    
          glEnable(GL_BLEND);
    
          glBegin(GL_QUADS);
            glTexCoord2f(x*ONE_16TH,y*ONE_16TH);
            glVertex2i(tx,ty);
    
            glTexCoord2f(x*ONE_16TH+ONE_16TH,y*ONE_16TH);
            glVertex2i(tx+16,ty);
    
            glTexCoord2f(x*ONE_16TH+ONE_16TH,y*ONE_16TH+ONE_16TH);
            glVertex2i(tx+16,ty+16);
    
            glTexCoord2f(x*ONE_16TH,y*ONE_16TH+ONE_16TH);
            glVertex2i(tx,ty+16);
          glEnd;
    
        end;
      end;
    And this is the output....

    CorrectResults.PNG

    So what I was doing wrong, was binding the palette texture to the vertices of the background colour. Instead, this code simply uses glColor4f to set the colour, then creates a quad, specifies the points for the background. Turns on blending, changes the colour and creates a quad, specifying texture coordinates corresponding to the required character.

    Interestingly though, I had a problem that was really odd involving the second column (from the left) and the bottom row, being darker. No matter what I tried I couldn't stop this and it was like this was something to do with one of the textures. Originally I was loading my textures and setting these:-

    Code:
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
    With those commented out, that problem went away.

    And that, as they say is that... now I can crack on and write some bad code to get something working.
    :: AthenaOfDelphi :: My Blog :: My Software ::

  7. #17
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,205
    Blog Entries
    2
    Forgot to add... thanks for all the suggestions chaps
    :: AthenaOfDelphi :: My Blog :: My Software ::

  8. #18
    I'm glad you got it working, and welcome back to coding

    cheers,
    Paul

  9. #19
    And this is the output....

    I'm glad you got it working!
    Try experimenting with glDisable(GL_BLEND) and see if it still works (unless your intention was blending the background with what was already rendered there).
    I think my advice earlier was wrong and you only need the test, without blending.

    you didn't see the link I've posted
    Sorry. You posted a link to a page with one paragraph of title text and some embedded rectangle that doesn't work without JavaScript. Okay, I temporarily enabled JS for slideshare.net and slidesharecdn.com. And what I see?

    A veritable wall of sites that suddenly want to run their JavaScript in my browser.
    How about NO?
    I alvays ignore such dumps of websites full of suspicious third party scripts.

    Added this to my hosts file:
    Code:
    127.0.0.1 www.slideshare.net
    127.0.0.1 slideshare.net
    127.0.0.1 slidesharecdn.com
    127.0.0.1 public.slidesharecdn.com
    so that that dump is always blocked.

    Besides, judging by the title that was something a nVidia dev said 9 years ago. Lots happened since then and I am more interested in the situation of today.

    On most desktop hardware we've done testing happens actually the opposite - glBegin/glEnd is close to performance to glDrawArrays
    That's a very interesting result and I can't wait until I'm done with my rehaul to do some more benchmarking.
    There must be some interesting dependency on driver version, operating system, the way you initialize GL or even if your app is 32 or 64-bit.
    Because I got what I got, both on Win7/HD3000/i5 and Win10/GTX460/Phenom II.

  10. #20
    Quote Originally Posted by Chebmaster View Post

    Sorry. You posted a link to a page with one paragraph of title text and some embedded rectangle that doesn't work without JavaScript. Okay, I temporarily enabled JS for slideshare.net and slidesharecdn.com. And what I see?
    A veritable wall of sites that suddenly want to run their JavaScript in my browser.
    How about NO?
    I alvays ignore such dumps of websites full of suspicious third party scripts.
    It's a web site that hosts a PowerPoint presentation made by aforementioned Nvidia person. I also use a JavaScript blocker in FireFox myself, but for occasional viewing open links in Chromium (Edge on Windows), which is something you can do for such exceptional cases. It's too bad you didn't care to check the presentation, especially for yourself as your attitude was a classical example of Dunning-Krueger effect: you have barely learned shader basics (as you've said yourself), so being a beginner you try to give advice whether to use a particular technology or not, while not being an expert on this topic; and you fear to see a presentation without enabling JavaScript, so can't actually learn something new. Please don't do that, such attitude hinders the real talent you may have.

    Here's a quote from that Nvidia presentation:
    NVIDIA values OpenGL API backward compatibility
    - We don't take API functionality away from you
    - We aren't going to foce you to re-write apps
    Does deprecated functionality "stay fast"?
    - Yes, of course - and stays fully tested
    - Bottom-line: Old & new features run fast
    Quote Originally Posted by Chebmaster View Post
    Besides, judging by the title that was something a nVidia dev said 9 years ago. Lots happened since then and I am more interested in the situation of today.
    "You have to know the past to understand the present." This Nvidia presentation talks about OpenGL 3.2, which is exact moment the whole deprecation thing happened. I obviously can't speak for graphics vendors, but I believe their commitment to continue supporting all OpenGL features in their graphics drivers is driven both by video games industry (there are a lot of old games that use legacy code; have you played Starcraft 1 recently? It still works and that's DirectDraw with direct primary surface access ) and enterprise sector, where you may find large code bases dating back to 90s.

    So it boils down to the same thing people said in Pascal vs C thread: use the tool that you find most appropriate for your current task.

Page 2 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL