DLL shading?

If you had access to the original program's source code, you could always call into a DLL function after rendering which would would grab the framebuffer and do whatever it wanted. But then again if you had access to the original source code you wouldn't need to resort to such a measure in the first place...

Other than that you'd need to have some way of knowing when the original application is finished rendering so you can somehow grab the framebuffer and perform you're processing. But just short of using an old-school OpenGL hack/hook I'm not sure how that would be done.

Thanks, so you say it's doable, right? Cool... Because i DO have the source code, but the programming language i make it in doesn't support shaders.

You need not use a DLL if you have the source and want to compile a new EXE. You could use a DLL if you wanted to, but either way you'll need to recompile the EXE (unless you plan to make things very difficult for yourself).

What you need to do is find the 'present'/'flip' routine and redirect it to a function of your own making. This function should take the back-buffer, which will be in some bitmap format or other, and copy it to a DirectX or OpenGL texture. You're then free to render this texture to the screen using whatever shaders take your fancy. It's kind of ad-hoc post-processing.

Things to consider:

1. Be sure to remove the original code responsible for writing to the screen.
2. Effectively, this turns a GDI (or whatever) application into a DirectX/OpenGL one in the most direct manner possible. This means that the process will have a bigger memory footprint (as it imports several more libraries) and won't be optimised. However, I doubt the performance hit will be noticeable.
3. As well as 'hooking' the buffer flip, you'll need to slip your own initialisation and deinitialisation routines in there, to set the screen up to work with your chosen graphics API and the likes.
4. I've assumed that the original program is indeed double-buffered. If not, you'll have to do a some work to adapt it so. Once something is written to the screen, there's very little you can do about it: grabbing the front-buffer and processing it will result in flicker at best, and disastrous DC clashes at worst.

Admiral

i don't quite understand you, TheAdmiral... and i DO need a DLL, because the .exe doesn't support shading, if u understand me :)

We don't understand you, that's the problem. If you have access to the source code, then you need to MAKE the application support shading. If you're trying to add it to an older application, then it's a lot more simple to put in a shading step at the end of the line (before it flips it to the screen), rather than trying to hook it all in a DLL and do it there. Can you elaborate a bit more on exactly why it MUST be in a DLL, if you already have the source code?

Quote:

Original post by Calipso i don't quite understand you, TheAdmiral... and i DO need a DLL, because the .exe doesn't support shading, if u understand me :)

How exactly do you plan on getting this DLL to do anything to the program if you're not going to recompile the EXE to use it? Without some nasty hacker tactics, this can't be done. And if you are going to recompile the exe, then you may as well compile the proposed DLL's functionality straight into the EXE, rather than going around the houses.

Admiral

if you mean that i can call the DLL directly from the exe... that's what i want to do... :D i know how to do that. What i was not sure about, is if i could take the rendered frame and jongle with it in the DLL b4 displaying it on the screen, and possbily how.

Quote:

Original post by Calipso if you mean that i can call the DLL directly from the exe... that's what i want to do... :D i know how to do that. What i was not sure about, is if i could take the rendered frame and jongle with it in the DLL b4 displaying it on the screen, and possbily how.

Yes. You can do exactly that. Reread my first post - it's all there. If you don't follow, say which bit loses you.

And I still think you're missing the point about using a DLL. Tell me what the difference is between DLL code called from an EXE and EXE code called from that same EXE.

Admiral

Quote:

Original post by Calipso ...the programming language i make it in doesn't support shaders.

Why so? Shaders are a programming language themselves and you use them via D3D or OpenGL objects. Those should be present in your language binding.

i want to make the shader stuff in a DLL because i make the game in GameMaker, and it doesn't do too good with shading. That's why i want to get it all externaly, because if i would make it all into the program, it wouldn't run at 5fps.

I see. You mean the language doesn't support linking with DirectX/OpenGL (rather than the exe not supporting shaders).
I don't know anything about Game Maker, but if you can access the back-buffer directly then you could indeed pass it to a DLL function, written in C++ or similar, to put the surface through a shader using Direct3D/OpenGL and finally onto the screen.

Does anyone know enough about Game Maker to say if this is possible? A quick search on the Game Maker forums suggests not.

Admiral

Sorry, but English is not my natal language, and i express myself in another way than that i want :D
btw....

Quote:

Thanks, so you say it's doable, right? Cool... Because i DO have the source code, but the programming language i make it in doesn't support shaders.

But can't the DLL access the backbuffer/frame rendered before it gets displayed, add a blur/bloom/fs effect and then render the result in the window handle given by the game?

I am curious, why do you use gamemaker, if you know both C++ and shader langauges?
If you do it because it is easy, i would suggest a third party engine, because they are faster and much more customizable.

because i know GM the best, and i'm more used to seeng it's UI than C++'s or nvidia's FXcomposer. And a bloom/shader fx would be a great addition to gamemaker games :P... and my game especially.