Arb Program Shader Epsxe
What Is the Best ePSXe Full-Screen Filter Setting? You can download and apply a Shader plugin for the ePSXe. ARB program' for Pete's OGL2.
Ah, the Horrible Old Days. It looks to me that the geometry being rendered has two surface normal texture maps, one 'normal' and one 'detail' presumably higher-res for close ups.
The vertex shader calculates the distance from the eye and scales it into a fraction of 250000, presumably the size of the world or far distance. The fragment shader gets the surface normal from the texture map, then adds a weighted fraction of the nearest detail surface normal using the distance value calculated by the vertex shader. This ensures that at a distance the surface normal doesn't keep changing drastically as the object moves. Then there's a standard ambient-diffuse-specular lighting calculation, although with an extra tweak at the comment 'Bias towards an up vector' The interesting bit starts with 'fresnel = (1 +' AFAIK that's used for calculating the distortion caused by viewing an object underwater. (Or an object in air if you're underwater.) The use of fragment position suggests there is a screen-resolution sized reflection/environment map. The 'offset reflection lookup' presumably gives the color of the fragment, which is then multiplied by the A-D-S lighting value.
As Grimmy suggests, you will almost certainly be better off figuring out what you want to achieve and writing directly in GLSL. Hope this helps.
Say that I have multiple shaders, linked in different programs. I was wondering what is the best way to switch between them.
I don't think I have to do the whole process again, starting from glCreateShader, do I? My guess is that linked programs are in the card's memory, and the steps I have to redo each time are the ones that move my shader, or my program, from the computer's memory to the card. I'm not sure it's right though, and I don't know exactly how to do it. It would be nice to have some insight.
Shaders can get complex for sure, but they're still very very small programs. Say a coupla thousand line C file is about 70k. Over 2 MB of C code can compile to an executable that's a coupla hundred K in size. That's the kind of size comparison we're talking about - absolute maximum - for all shaders (not each shader). By contrast a 512x512 texture is 1MB. Now look at the lifetime of a shader. It's created, it's used and it's destroyed.
Best Epsxe Shader
A shader is only uploaded to video RAM when initially created, and this should be a one-time only operation. Each time you use it it's just set as 'active' (or whatever happens behind the scenes); the actual act of using a shader doesn't consume any extra memory so there's no need for paranoia on that count. Then when you destroy it that memory is released. Now consider the memory-saving option. Instead of creating shaders as a one-time-only operation you instead create and destroy them as required. Your program will run slow, because creating a shader is - like creating any object - a complex and time-consuming operation.
And all to save a few kilobytes. And now consider the purpose of memory. It's a resource. And if you're not using it, it's lying idle. Doing nothing for you.
So (and pardon my language here ) you're not some kind of goddam hero for only using a few MB of a 1 GB card, you're actually wasting the memory that you don't use. That's not to say that you should go berserk with memory (in which case you're definitely not some kinda goddam hero!), just that being ultra-frugal has a very low return on investment, and often at the expense of performance. So to sum up; what applies to shaders also applies to any other object you create in VRAM.
Epsxe Shader Missing Custom File
Textures, VBOs, etc. And of all of these, shaders will consume by far the least amount of memory (like I said at the start, even a single texture can overwhelm the amount of memory that shaders use). So if you're going to optimize memory usage you should be looking at textures and VBOs first, and only consider shaders if even after that you're really really tight. And glUseProgram is really no different to glBindTexture or glBindBuffer; it just selects a currently active object. Would you have memory concerns about glBindTexture or glBindBuffer? (OK, I didn't mean to turn that into a semi rant.
(OK, I didn't mean to turn that into a semi rant. )It was actually a very interesting post, thank you.
You made a mistake with your last line though, because another question is coming. I'll go a bit off topic in my own thread.
The thing is that while I was just under the impression that I had to remove shaders from memory, I was actually pretty sure that I had to remove other objects. Looking at an array buffer, with so many vertices in a picture it must take some memory already. However I guess I always need an array buffer, or I have no image.
But other buffers, and the textures. That's quite some space, isn't it? Are you saying I should leave everything in the video memory?
At no time should your main rendering loop involve the creation or destruction of objects (except for certain buffer object streaming cases, and even then you're just calling glBufferData or glMapBufferRange with invalidate, not glGenBuffers/glDeleteBuffers). If you have a buffer object, then you are using it for some purpose. If you will need the contents of that buffer object next frame, then there's no purpose in deleting it. If you will need the contents of that buffer object two frames from now, again, there's no purpose. You can keep going from there. The only time you should remove objects is when you're not going to need them for the forseeable future, a time best measured in seconds or minutes. In the context of a game, this would be when the player leaves the area where that mesh/texture is used.
In a modeling-type application, you delete it when the user deletes it. And if you're dealing with a streaming world like GTA or whatever, then you shouldn't even delete the object; just upload new data to it for any new meshes/textures that become available as you move from one place to another.