this post was submitted on 11 Oct 2024
6 points (100.0% liked)

Learn Programming

1656 readers
1 users here now

Posting Etiquette

  1. Ask the main part of your question in the title. This should be concise but informative.

  2. Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.

  3. Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.

  4. Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 2 years ago
MODERATORS
 

Vertex:

#version 120

void main() {
	gl_TexCoord[0] = gl_MultiTexCoord0;
	gl_Position = ftransform();
}

Fragment:

#version 120

uniform sampler2D tex;

void main(){
    vec4 texSlmp = texture2D(tex, gl_TexCoord[0].st);
    gl_FragColor = vec4(texSlmp.r, texSlmp.g, texSlmp.b, 1.0);
}

All I get with this is a black screen.

I cannot seem to get tutorials for anything older than OpenGL 3.3, and for my usecase, I could go lower, except everyone tells me "OpenGL is obsolete, try Vulkan instead".

gl_TexCoord[0] seem to be all zeros if I modify the fragment shader to try to output gl_TexCoord[0].st, so its content would be displayed as color information, which I did for a different test. Also I can't find anything on how do I "pass" textures (or other values) to the shaders in the official docs, nor any of the tutorials I could find explains how that actually works.

EDIT: Target version is OpenGL 2.1/GLSL 1.20

EDIT2: I updated the shaders to GLSL 3.30, but then my DuckDuckGo search results suddenly turned bad about the subject, and in/out still doesn't work between vertex and fragment shaders (values taken from the vertex shader is all zero).

top 6 comments
sorted by: hot top controversial new old
[–] graphicsguy 2 points 2 months ago (1 children)

Download renderdoc: https://renderdoc.org/ It's a great, easy graphics debugging tool.

There, you should be able to inspect your draw call and see what's going wrong.

But also, on the topic of API's. OpenGL is basically obsolete as you suggested, but Vulkan / DX12 / Metal are a huge pain. I'd recommend DX11 if you have windows access, or WebGPU if you don't. For WebGPU you can write it in javascript or natively in C++ / Rust (good tutorial here: https://eliemichel.github.io/LearnWebGPU/)

That being said, if all you want to do is live on the shader side and you don't want to write the API side, then Electronic Arts recently open sourced a great tool called GiGi that lets you get right down to authoring shaders and connecting them together. Think ShaderToy but WAY MORE FEATURES. https://github.com/electronicarts/gigi

[–] [email protected] 1 points 2 months ago

I appreciate the renderdoc, but the rest has a big "Catching mice is deprecated, recommend relying on humans instead." vibe to it.

Issue with DX is that I don't want to lock myself into Microsoft stuff, especially as they're forcing ML bullshit onto their users. I've heard of WebGPU, but thanks for its name, I thought it was a "web-only" thing, also I don't want to write even the most computationally heavy things in JS.

Since I'm writing stuff in D, I can just use nuvk in the future, maybe by translating OpenGL calls to nuvk calls, which it will translate to Vulkan or Metal.

[–] refalo 1 points 2 months ago* (last edited 2 months ago) (1 children)

You don't say what your target OpenGL (or GLSL) version is, and we need to see your setup code as well. Typically gl_MultiTexCoord and ftransform isn't used since ancient times.

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago) (1 children)

Updated, target version is OpenGL 2.1/GLSL 1.20

[–] refalo 1 points 2 months ago* (last edited 2 months ago) (1 children)

I'm curious why you want to target 2.1 specifically? A lot of drivers these days don't go below 3.x

And just changing the shader to #version 330 often isn't enough, that's why we need to see your setup code either way.

Preferably a minimally reproducible example project that we can build and test to be able to tell you exactly what's wrong with your code.

[–] [email protected] 1 points 2 months ago

Okay, I've changed things around, it seems there was a typo, I fixed it, now I'm getting access violation errors from nvoglv64.dll.