0
\$\begingroup\$

I have come across a problem when I am loading a single texture onto a single quad, and this problem persisted during the planning phases of my project, before starting my development phase. I am confused on the order of operations required to load a texture.

Why am I confused? I used the order listed below and rewrote the project over and over again, and the results vary. As in, one project would load and display the texture correctly, while the other projects can't display the texture, but loads the texture just fine. Due to this, I am conflicted.

Here is the rundown on the order of operations required for me to load a texture and show it onto the screen using OpenGL 2.0.

  1. Create window.
  2. Set up game loop.
  3. Create OpenGL 2.0 context.
  4. Initialize objects and load necessary files and data. (Textures, bitmaps, etc.)
  5. Set up vertex data. (In this case, a quad.)
  6. Create vertex shader code.
  7. Create fragment shader code.
  8. Compile the codes. (Checking included.)
  9. Create program.
  10. Attach shaders to program.
  11. Link.
  12. Validate.
  13. Obtain attribute and uniform locations.
  14. Set up viewport.
  15. Create projection matrix, be it perspective or orthogonal.
  16. Create view matrix and initialize matrix state.
  17. Set vertex attribute pointer.
  18. Enable vertex array buffer.
  19. Use view matrix as model matrix. Push/pop/transform when necessary.
  20. Clear screen.
  21. DrawArrays().

Are these correct in chronological order? Are there anything else I am missing? I am just stuck on the planning phase, and wanted to get the chronological order done right.

\$\endgroup\$
  • 1
    \$\begingroup\$ You're describing what you are doing in high level while the problem is more likely code specific. Anyway there is no correct chronological order for every application, the point is to understand how every API call works and then you will see how flexible things can be. \$\endgroup\$ – concept3d Feb 6 '14 at 11:38
  • \$\begingroup\$ So, if I don't understand how the API calls work, any order of operations are just meaningless? I guess I should just ask with the problem in the code first. \$\endgroup\$ – tom_mai78101 Feb 7 '14 at 11:07
  • \$\begingroup\$ Try a graphics debugger, like AMD's CodeXL or apiTrace. There is quite possibly some error being thrown by GL that you're missing. \$\endgroup\$ – Sean Middleditch Feb 8 '14 at 3:14
-1
\$\begingroup\$

write the code, compile it, run it. when it works on all gpu's your planning was correct. If it pleases you: I have my approval that your planning is reasonable and worth testing out.

and make shure you always use ther correct active texture unit. That active texture thing (glActiveTexture) is there to confuse people how are new to opengl. you do not pass the texture id to the shader uniform, it is always the number of the texture unit.

\$\endgroup\$
  • \$\begingroup\$ Actually, that active texture thing is there to give the driver developers a way to expose multiple texture units to application developers, nothing more. \$\endgroup\$ – MickLH Feb 8 '14 at 8:50
  • \$\begingroup\$ No, you are wrong. This active texture thing was a way to support multi texturing in the fixed function pipeline. Without the fixed function pipeline it is just another layer of indirection that nobody needs anymore. \$\endgroup\$ – Arne Feb 9 '14 at 13:32
  • \$\begingroup\$ Sorry, you are too confident in your (emotional) stance on this topic. The API of OpenGL is based on manipulating state, and whether you use shaders or the fixed function pipeline is irrelevant: Setting texture sampler parameters to the active texture unit is the core OpenGL way (consistent with the rest of the API) of controlling texture units. \$\endgroup\$ – MickLH Feb 9 '14 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.