Any chance of this incorporating features from DX 10 or 11?

I went and got GLEW now and only gem fails to compile.

I think a lot of MGE's speed issues are related to the code, how it's half-untangled spaghetti, and how much stuff is repeated or cached. The depth rendering and menu stuff and everything involved there doesn't help. How water is handled certainly doesn't, since it combines a lot of the worst parts of the rest. I'm going to test speed on caching draw calls and doing all the normal ones, then all the depth/water ones compared to just swapping render targets and drawing twice when the engine calls it the first time. Not sure as to all of it, but as I try to get water and distant land working, I'll certainly be playing with different techniques and seeing which are faster. Maybe patching MGE, if I find anything useful.


In Gem itself, I'm not sure. Making a DX 8.10 wrapper might not be the easiest thing, I haven't looked at it. My system though, and Cg under it, supports DirectX 8, 9, 10 and 11, as well as OpenGL. So any game using one of those is fair game for shaders.


Odd, only the Frost module uses Glew, and I don't think that will even compile yet. If you can post or PM me the errors you get, I'll take a look. Are you using the latest revision and rebuilding all the projects?

I don't know if it's related but it just works now. I pulled the latest revision with the updates as of 15 or 16 hours ago. Give me a sec to compile quick and find the errors.

Got a new build, will upload and send out first thing in the morning.



The gist of that is that it can't find the library. Try checking the paths and make sure the solution's bin directory is set up as a lib include.

That's probably my problem, i'll go do that quick and report back.

Edit: Turns out it compiles now.

Well, I've received 2 successful test reports on the last build, so (for the time being) I'm going to post the message and links here that I sent out. Anyone wanting to try it, in the very limited state it is in, is welcome to.



Questions, comments, first impressions, bugs, crashes, suggestions, etc, please let me know.

The full source code is available here: https://github.com/peachykeen/VoodooShader
and the entire project is released under the GPL v2 (same as MGE). If you're code-savvy, you can take a shot at building it, but be aware you need Boost and the Cg Toolkit (from Pjstaab's relative success, I think everything else is set up properly, more or less).

I'll also be uploading full documentation, both for code (API) and general stuff, as soon as I get it generated and uploaded neatly. I'll also be keeping a running list of games that are or will be compatible, and opening a bug tracker for any issues folks run into.

With any luck, we can see this be a fully working framework soon and I've got a few fun features planned to try out (ever wanted to paint a picture in game and save it? gonna take a shot at that).




Cool, if you notice anything interesting, let me know.

One thing I noticed, when I went to install it, it didn't overwrite MGEs d3d8.dll. I deleted MGEs and it installed just fine. Starting Morrowind now.

Shadered Portion works with intro cutscenes and menu with steam overlay but the main game does not. Testing now without steam overlay.

Still doesn't work with overlay disabled.
http://img440.imageshack.us/img440/4318/morrowind20110105183809.png
http://img28.imageshack.us/img28/2668/morrowind20110105183807.png

Ingame works now with overlay disabled though.
http://img222.imageshack.us/img222/1592/morrowind20110105184109.png

And infinite screens are cool.
http://img836.imageshack.us/img836/9128/morrowind20110105184318.png

Downloaded both the core and Gem installers and installed them. I can confirm what Pjstaab said about MGE's d3d8.dll not being overwritten. Deleting it and reinstalling Gem, solved the issue. Everything works fine in game but, for some funny reason, I can't take a screenshot (it keeps telling me to set Screen Shot Enable to 1 in MW.ini, but it's already enabled). Anyway it looks like the screenshots of Pjstaab. If it can be of interest, I have good old 2002 MW with TB and BM + patch to 1.6.1820 - no steam or GOTY Edition.

I also had to delete the MGE .dll as the Voodoo Gem one didn't overwrite
AND It works well IF I also delete/remove "dinput8.dll" from MGE, from the morrowind directory. So there seems to be a definite MGE conflict.
I am using the latest MGE SVN & not the stable one.
Other than that it was pretty speedy, although W/O MGE's settings and distant land it should have.
I look forward to the next vers.

I think the d3d8.dll has to do with versions, the installer is set up to only over-write DLLs with earlier versions than mine. The best solution at the moment is to rename your MGE d3d8.dll to mge_d3d8.dll, then when you switch back (since it's just a test version), delete or name the Gem one to gem_d3d8.dll.

The screenshots show what should happen, this was purely a basic test of the hook system and such. I was talking with a friend last night who does some development and got a few ideas there, so I might rework some stuff to be more stable, but things will stay generally the same.

I'm not sure as to the ScreenShotEnable bit, I've been having teh same problem but not related to Gem.

I figured screenshots not working was the same as why it doesn't work with MGE so I just used fraps. I'm using the Steam version of Morrowind FYI for any future bugs I find.

I would assume the issues are the same, I'll add a screenshot mechanism soon. Good to know it works on Steam and regular.


For updates, I've been working on the core and getting that more stabilized. With Gem functional, I've also been improving the other game modules and working with folks in those communities. I've also been trying to get into an internship, so I've had to do some work on other stuff (hence no new test copies in the last few days).

There seems to be a bug with 64-bit systems in Gem, I think it's related to the registry and am tracking it down now, just need to test under my 7x64. If anyone willing and able to test has a 64-bit OS (I think I have 2 folks with that setup right now), please let me know.

I'm doing some work on a few internal bits to simplify the build and make things faster, almost done with that. Next test will have multipass shaders and, if I can get the file system working, test loading images from external sources. After that comes deferred rendering, then materials, and the basics will be done (both those systems are in place in the core, just not set up to work with MW/Gem yet).

For image support, I'll be using DevIL, so the two best formats (PNG and DDS) will be available, as well as HDR (yes, Voodoo will support true HDR, both in textures and shaders), BMP, TGA, even PSD, JPEG and maybe GIF. More details here: http://openil.sourceforge.net/features.php

What about 64-bit isn't working? I can check it out quick. I was also excited about seeing recent updates but then was sad after it was just documentation.

I have Windows XP Pro 64-bit with SP2. If you explain what I need to do in simple language for me (I'm not super duper savvy with these things), I'd be happy to run some tests for you.

So, how goes work on this if any?

I would like to second the above question.

Been a while since I updated this, but development certainly hasn't stopped. More like I've been too busy with it to run around hitting all the forum threads .

Been putting in a ton of code, reworking and optimizing things, and adding features like crazy throughout the last month, and now coming to the testing-before-release bit. I hope to have another test out very shortly (Valve-time), with all the previous bugs squished and a some new features.

As I go along, the system has been continually worked and reworked and improved, to be fast, sturdy and unified. I started on the NWN support the other day and it took about 3 days to get the basics set up and running for a totally different game.

In my latest tests, there's still no FPS hit from running a test shader, everything seems very stable. When something does go wrong, the error log (kind of a new concept in these parts, I know ) tracks down what info it can and takes note. A pretty viewer is included to load the logs and highlight any warnings or errors.

I've also started implementing the config system. Voodoo, in this, follows a very different style from MGE or previous apps of the sort. There's one config file (xml, pretty small and readable if you want) and a tiny (15kb) hook DLL in the Morrowind directory, and that's it. The hook finds the rest of the files from the registry and loads them up dynamically, then core reads the config and sets things up. Everything can be tweaked and changed, and most of the stuff is set in the config. To be able to cope with many games, I had to set up a system of handling DLLs that can be swapped out, which I poked at a bit and extended into a full-blown plugin system (no more hacky plugins for MWSE, just write up a DLL and add it to the config).

The hook and core are game-independent and so allow Voodoo to load into most programs, it's the config and adapter that specialize things. The setup for an adapter is fully documented and explained http://docs.voodooshader.com/core/adapterspec.html and http://docs.voodooshader.com/core/class_voodoo_shader_1_1_i_adapter.html, so they'll all behave the same and features will work as expected. I've also been testing the core every time I test any adapter, so it gets quite a bit of work and is passing with great results so far.

The resource handling system has been implemented and works perfectly (first try, too! ). A set of paths are given in the config and searched in order, so you can store per-install resources in the install folder, per-user in my documents, or keep everything neat and clean in the main voodoo folder. As usual, shaders work between games, so you rarely need game-specific stuff. A working example of the config setup https://github.com/peachykeen/VoodooShader/blob/master/Resources/VoodooConfig_Gem.xmlconfig.

Texture loading has also been added. The details will probably only interest artists, but I'm using DevIL to handle loading textures, so pretty much any format you want can be handled. Everything from BMP and JPEG (which I really don't recommend) to 48-bit PNG, or full 128-bit DDS or HDR textures. Voodoo fully supports true HDR (where hardware allows it). Full info on that here: http://docs.voodooshader.com/core/_textures.html

The material system is mostly set up, just need to add the final touches on that and get it working nicely. Need to set up a config app, but that'll come a bit later. The next test release won't have everything complete, but it will have a few more fun things.

The code is available on Github and I've resumed almost nightly pushes there, so anyone curious or wanting to help out can play with it. As usual, everything is documented. I absolutely refuse to let this go the way of MGE's code or wiki, despite a much larger scope, so I've taken care to note everything as I go along. The documentation is in the code and I use doxygen to generate it each time I upload the codebase, so it will stay pretty up-to-date and comprehensive. The full documentation for the core and current modules is hosted at http://docs.voodooshader.com/core and adapters will be added as I finish up the docs for them.

Edit: Oh yeah, and I figured out and fixed the 64-bit bug. It ended up being pretty simple, and instructions on what causes it and how to avoid it (it's a windows deal, how it handles the registry) will be included in the readme.


And finally, a few screenshots. All in 3D:
http://i4.photobucket.com/albums/y145/peachykeen000/a_desert_storm/MGEScreenshot058.png
http://i4.photobucket.com/albums/y145/peachykeen000/a_desert_storm/MGEScreenshot059.png
http://i4.photobucket.com/albums/y145/peachykeen000/a_desert_storm/MGEScreenshot057.png

(april fools )

Damn! Keep it up! It looks great.

Gosh, I say to this!

I very much look forward to this, especially since I hope your implementation of shadows will be somewhat kinder to my oldish laptop than MGEXE.

I can't promise shadows will be spectacularly fast, since they're somewhat involved by necessity. I do have a few ideas I'm poking at with shadows that might make them cooler, but testing the speed and feasibility will tell whether they work or no.

Per-pixel lighting throughout (once the material system is finalized) will also be in there, and combined they offer a few very interesting possibilities (normal and parallax mapping and such). Definitely a step or 10 beyond what Oblivion offers. Might be able to put MW on par with Skyrim.

Something else I'm not sure I mentioned is that, in line with the plugin system, I have a few little things planned there. One of the notable ones is using the MyGUI system, which supports a pretty smooth UI setup (OpenMW is using it, I believe), to add scriptable and custom menus. Have to see where that goes before I can tell for sure, though. If it does work out, it supports Chromium widgets and in-game textures, so we might be able to toss the internet into good ol' Morrowind. Have to see.

Also, scripting for plugins will work similar to MWSE's external app scripting, in my current concept, but not have the issues of using named pipes and such (simpler and less crashy).

<33333!

I'm not sure if this is at too early a stage for me to ask, but would exempting specific meshes from shaders be feasible or possible? Or indeed, targeting only specific meshes?
For example, if you wanted to make a distant blur shader that didn't affect the sky, or a detect life spell that works like the one in Oblivion.

Regardless, your progress on this is encouraging.

Quit playing RL 2011 and get to finishing this peachykeen!

Finally, no more alt+tabbing!

At the moment it's not based on meshes, but on textures. I'm not sure how well applying the material to the whole mesh would work, it may actually cause some problems.

Once the shader is on the material, you can do whatever you want with it. Quite a few render modes are supported (how alpha is handled, z-ordering and such), and each pass can specify how it wants the render to be handled. You could even specify a target and render to a texture instead of the screen and recombine them later.

Edit: Oh, and not doing the sky is just a matter of setting a far-distance to the distant blur.