DirectX 11 render system - work-in-progress

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
ahmedismaiel
OGRE Contributor
OGRE Contributor
Posts: 217
Joined: Wed Jan 25, 2006 11:16 pm
Location: Redmond,WA

Re: DirectX 11 render system - work-in-progress

Post by ahmedismaiel »

Crashy :do you know how long it takes to get your changes in the trunk ? it is very hard to merge your changes with mine

also checking if my proposed changes made it in before syncing the trunk
Crashy
Google Summer of Code Student
Google Summer of Code Student
Posts: 1005
Joined: Wed Jan 08, 2003 9:15 pm
Location: Lyon, France
x 49
Contact:

Re: DirectX 11 render system - work-in-progress

Post by Crashy »

I don't know how long it is. The .patch is weird because tortoise hg generated a diff file for DX11RenderSystem.cpp removing all lines and adding all lines....I don't know why as the mirror of the repository I use to create patches is always a clean one, with no modifications at all. Don't know how to solve this.
Follow la Moustache on Twitter or on Facebook
Image
User avatar
Beauty
OGRE Community Helper
OGRE Community Helper
Posts: 767
Joined: Wed Oct 10, 2007 2:36 pm
Location: Germany
x 39
Contact:

Re: DirectX 11 render system - work-in-progress

Post by Beauty »

Mind Calamity wrote:And I made a wiki article to help anyone who has the same problem/question as me.
Good boy. Thank you. :D
Help to add information to the wiki. Also tiny edits will let it grow ... :idea:
Add your country to your profile ... it's interesting to know from where of the world you are.
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

BTW, I don't think "preprocessor defines" code in D3DHLSLProgram is correct. The D3D10_SHADER_MACRO are struct of LPCSTR. But the way it's implemented the LPCSTR points to strings on the stack. So when the function returns they point to garbage values. I did a quick fix to load the defines into std::pairs residing in a std::vector and then point the LPCSTR at that. ATM it seem to work in my test shaders but I have to think about the implications of using LPCSTR on std::pairs in a std::vector. It's probably right tho.

Update: You can just pass in stringBuffer to the getDefines() static function and it works. So yeah, previously DX11 preprocessor defines was not working.
Last edited by LBDude on Tue Dec 06, 2011 9:44 pm, edited 1 time in total.
My blog here.
Game twitter here
User avatar
boyamer
Orc
Posts: 459
Joined: Sat Jan 24, 2009 11:16 am
Location: Italy
x 6

Re: DirectX 11 render system - work-in-progress

Post by boyamer »

Anybody of you got constant buffers working?

I think it can be archieved in this way:
1) Allocate them on GpuProgramParameters side, when setNamedConstant is called write to appropiate
memory, during binding to Gpu, there will be performed multiple Map/Unmap of DX11/GL3.0+ buffers and setted to device.

2) New type of HardwareBuffer like VertexBuffer/IndexBuffer/PixelBuffer and map, unmap everytime access to setNamedConstant method.

What do you think about?
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

Crashy wrote:I don't know how long it is. The .patch is weird because tortoise hg generated a diff file for DX11RenderSystem.cpp removing all lines and adding all lines....I don't know why as the mirror of the repository I use to create patches is always a clean one, with no modifications at all. Don't know how to solve this.
Hey I couldn't merge OgreDX11RenderSystem.cpp so I manually did it using Emacs.

http://pastebin.com/SmEdbKW2

I still can't get SV_Target1 to show up tho.

Update: Nevermind. DX11 MRTT works for me after applying Crashy's patch, manually merging one of the files. One of my render targets had a different mip map setting than my other render target, that's why it didn't render.
My blog here.
Game twitter here
User avatar
ahmedismaiel
OGRE Contributor
OGRE Contributor
Posts: 217
Joined: Wed Jan 25, 2006 11:16 pm
Location: Redmond,WA

Re: DirectX 11 render system - work-in-progress

Post by ahmedismaiel »

this is great ,we are using MRT in our game with d3d9 and i can try it d3d11
LBDude : could you create another patch after your merge ? that will make it much easier for me to merge my stuff with it
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

ahmedismaiel wrote:this is great ,we are using MRT in our game with d3d9 and i can try it d3d11
LBDude : could you create another patch after your merge ? that will make it much easier for me to merge my stuff with it
http://pastebin.com/ZMf9Hj4f

You can try this not guaranteeing that it will work for you. Also I agree to licensing with respect submitting a patch to Ogre.
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

Anyone got HDR compositor to work with DX11? I ported the HLSL shader over to SM_4 but I'm getting glitchy results.
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

So I've got the HDR compositor to work in DX11/10. I will upload the shaders somewhere in case anyone want to try it out. I have a problem with it tho because my deferred light shader spits out NAN pixels for some reason. This causes problems with the lum. shader because--gargabe in gargabe out--NaNs becomes the lum. value, causing the screen to go black. I resolved this by doing a check on that.

Anyone having issues with Depth Sharing in DX11/10? I was stepping through debugger it doesn't seem to be executing the depth sharing code path. I need this in my deferred light shaders because if I don't do a ZPASS for deferred lights the result are incorrect, only when I do a ZPASS the results are correct. So this means the depth is not being shared with a former render target, in my case the GBuffer producer.

Update: I've fixed the depth sharing issue. Depth sharing works. I had setClearEveryFrame(true) on one of my render targets. If you have this set as true the render target clears the depth on every update invocation.
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

Hey I read some of the posts regarding issues with texture usage and access. Can you not instead of using two textures for locking and copying, use D3D11_USAGE_STAGING, then MAP the resource on lock, UNMAP on unlock AND CopyResource to GPU. I'm planning to try this right now. From the MSDN docs it seems you can do this but then I found a direct compute tutorial that seems to be doing this:

http://openvidia.sourceforge.net/index. ... ectCompute
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

Hey I read some of the posts regarding issues with texture usage and access. Can you not instead of using two textures for locking and copying, use D3D11_USAGE_STAGING, then MAP the resource on lock, UNMAP on unlock AND CopyResource to GPU. I'm planning to try this right now. From the MSDN docs it seems you can do this but then I found a direct compute tutorial that seems to be doing this:

http://openvidia.sourceforge.net/index. ... ectCompute

Why I need this? I have a 512x512 texture which I create on initialization. I then "page" into this texture on an irregular basis by lock->write->unlock. Works fine in DX9. But in DX10 TU_DYNAMIC code path is implemented and works fine, but not for the other usages. It didn't work for my case because right now it just allocates an temp. buffer on locking, then CopyResource that buffer on unlock. This behavior is equivalent to DISCARD, which I can't use because I only update a section on the buffer. By implementing D3D11_USAGE_STAGING, I hope what happens is I can map that entire resource on the CPU, UPDATE ONLY A SECTION OF THAT, unmap, then resource copy to the GPU. 'm fine with locking the entirety of that resource. But I only need to upload sections of it to the GPU.
My blog here.
Game twitter here
Zero
Halfling
Posts: 50
Joined: Mon Mar 10, 2008 12:08 am
Location: Stuttgart|Germany
x 1
Contact:

Re: DirectX 11 render system - work-in-progress

Post by Zero »

The Problem is, that you cant use a staging texture with a shader.

@Updating Parts: For me it works to update only parts of the texture. Maybe I fixed it with a patch of me, I uploaded it, but I don't know if it was already merged.

Edit: http://sourceforge.net/tracker/?func=de ... tid=302997 This is the patch.
Image
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

Thanks. My copy doesn't contain your changes. You changes are exactly what I need!
My blog here.
Game twitter here
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: DirectX 11 render system - work-in-progress

Post by LBDude »

Update: The crash was related to loading Cubic environment map. I have it disabled for now, will try to figure out the problem later on.


Hey I've successfully merged your code. My texture paging code is working because I can see correct output on my debug overlay, but it still crashes at a later point, when loading some random texture (I think it's some temp. HDR compositor texture). At first I was using TU_STATIC with HBL_WRITE_ONLY, but that crashes in unlockimpl because in lockimpl _mapStaging() is called with HBL_WRITE_ONLY, but _unmapStaging is not called later to undo it. It works fine when I use TU_DYNAMIC and HBL_NORMAL. Still crashes at a later point, though.

ogre.log

Code: Select all

....
D3D11 : ***** Dimensions altered by the render system
D3D11 : ***** Source image dimensions : 0x0
D3D11 : ***** Texture dimensions : 16x16

Code: Select all

if(mUsage == HBU_STATIC || mUsage & HBU_DYNAMIC)
		{
			if(options == HBL_READ_ONLY || options == HBL_NORMAL || options == HBL_WRITE_ONLY)
				rval.data = _mapstagingbuffer(flags);
			else
				rval.data = _map(mParentTexture->getTextureResource(), flags);

			// calculate the offset in bytes
			offset = D3D11Mappings::_getSizeInBytes(rval.format, rval.left, rval.front);
		}
....
if(mUsage == HBU_STATIC)
		{
			if(mCurrentLockOptions == HBL_READ_ONLY || mCurrentLockOptions == HBL_NORMAL)
				_unmapstagingbuffer();
			else
				_unmapstaticbuffer();
		}

Code: Select all


 	OgreMain.dll!Ogre::HardwarePixelBufferSharedPtr::HardwarePixelBufferSharedPtr(const Ogre::HardwarePixelBufferSharedPtr & __that)  + 0xd bytes	C++
>	RenderSystem_Direct3D11.dll!std::_Cons_val<Ogre::STLAllocator<Ogre::HardwarePixelBufferSharedPtr,Ogre::CategorisedAllocPolicy<0> >,Ogre::HardwarePixelBufferSharedPtr,Ogre::HardwarePixelBufferSharedPtr>(Ogre::STLAllocator<Ogre::HardwarePixelBufferSharedPtr,Ogre::CategorisedAllocPolicy<0> > & _Alval, Ogre::HardwarePixelBufferSharedPtr * _Pdest, Ogre::HardwarePixelBufferSharedPtr && _Src)  Line 280 + 0x1d bytes	C++
 	RenderSystem_Direct3D11.dll!std::_Uninit_move<Ogre::HardwarePixelBufferSharedPtr *,Ogre::HardwarePixelBufferSharedPtr *,Ogre::STLAllocator<Ogre::HardwarePixelBufferSharedPtr,Ogre::CategorisedAllocPolicy<0> >,Ogre::HardwarePixelBufferSharedPtr>(Ogre::HardwarePixelBufferSharedPtr * _First, Ogre::HardwarePixelBufferSharedPtr * _Last, Ogre::HardwarePixelBufferSharedPtr * _Dest, Ogre::STLAllocator<Ogre::HardwarePixelBufferSharedPtr,Ogre::CategorisedAllocPolicy<0> > & _Al, Ogre::HardwarePixelBufferSharedPtr * __formal, Ogre::HardwarePixelBufferSharedPtr * __formal)  Line 431 + 0x8 bytes	C++
 	RenderSystem_Direct3D11.dll!std::vector<Ogre::HardwarePixelBufferSharedPtr,Ogre::STLAllocator<Ogre::HardwarePixelBufferSharedPtr,Ogre::CategorisedAllocPolicy<0> > >::reserve(unsigned int _Count)  Line 760	C++
 	RenderSystem_Direct3D11.dll!std::vector<Ogre::HardwarePixelBufferSharedPtr,Ogre::STLAllocator<Ogre::HardwarePixelBufferSharedPtr,Ogre::CategorisedAllocPolicy<0> > >::_Reserve(unsigned int _Count)  Line 1297 + 0x1f bytes	C++
 	RenderSystem_Direct3D11.dll!std::vector<Ogre::HardwarePixelBufferSharedPtr,Ogre::STLAllocator<Ogre::HardwarePixelBufferSharedPtr,Ogre::CategorisedAllocPolicy<0> > >::push_back(Ogre::HardwarePixelBufferSharedPtr && _Val)  Line 650	C++
 	RenderSystem_Direct3D11.dll!Ogre::D3D11Texture::_createSurfaceList()  Line 695 + 0x20 bytes	C++
 	RenderSystem_Direct3D11.dll!Ogre::D3D11Texture::_setFinalAttributes(unsigned long width, unsigned long height, unsigned long depth, Ogre::PixelFormat format)  Line 596	C++
 	RenderSystem_Direct3D11.dll!Ogre::D3D11Texture::_loadTex(Ogre::SharedPtr<std::vector<Ogre::SharedPtr<Ogre::MemoryDataStream>,Ogre::STLAllocator<Ogre::SharedPtr<Ogre::MemoryDataStream>,Ogre::CategorisedAllocPolicy<0> > > > & loadedStreams)  Line 261	C++
 	RenderSystem_Direct3D11.dll!Ogre::D3D11Texture::loadImpl()  Line 129	C++
 	OgreMain.dll!Ogre::Resource::load(bool background)  Line 241	C++
 	OgreMain.dll!Ogre::TextureUnitState::ensureLoaded(unsigned int frame)  Line 1145	C++
 	OgreMain.dll!Ogre::TextureUnitState::_load()  Line 1026 + 0x8 bytes	C++
 	OgreMain.dll!Ogre::Pass::_load()  Line 1245 + 0x7 bytes	C++
 	OgreMain.dll!Ogre::Technique::_load()  Line 594 + 0x7 bytes	C++
 	OgreMain.dll!Ogre::Material::loadImpl()  Line 161 + 0x7 bytes	C++
 	OgreMain.dll!Ogre::Resource::load(bool background)  Line 241	C++
 	OgreMain.dll!Ogre::ResourceManager::load(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & name, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & group, bool isManual, Ogre::ManualResourceLoader * loader, const std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,Ogre::STLAllocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,Ogre::CategorisedAllocPolicy<0> > > * loadParams, bool backgroundThread)  Line 107	C++
 	OgreMain.dll!Ogre::ManualObject::ManualObjectSection::getMaterial()  Line 1065 + 0x22 bytes	C++
 	OgreMain.dll!Ogre::Renderable::getTechnique()  Line 168 + 0xa bytes	C++
 	OgreMain.dll!Ogre::MORecvShadVisitor::visit(Ogre::Renderable * rend, unsigned short lodIndex, bool isDebug, Ogre::Any * pAny)  Line 452	C++
 	OgreMain.dll!Ogre::ManualObject::visitRenderables(Ogre::Renderable::Visitor * visitor, bool debugRenderables)  Line 900 + 0x12 bytes	C++
 	OgreMain.dll!Ogre::MovableObject::getReceivesShadows()  Line 462	C++
 	OgreMain.dll!Ogre::RenderQueue::processVisibleObject(Ogre::MovableObject * mo, Ogre::Camera * cam, bool onlyShadowCasters, Ogre::VisibleObjectsBoundsInfo * visibleBounds)  Line 305 + 0x25 bytes	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeNode::_addToRenderQueue(Ogre::Camera * cam, Ogre::RenderQueue * queue, bool onlyShadowCasters, Ogre::VisibleObjectsBoundsInfo * visibleBounds)  Line 186	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 651	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 672	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 672	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 672	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 672	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 672	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 672	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 672	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::walkOctree(Ogre::OctreeCamera * camera, Ogre::RenderQueue * queue, Ogre::Octree * octant, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool foundvisible, bool onlyShadowCasters)  Line 687	C++
 	Plugin_OctreeSceneManager.dll!Ogre::OctreeSceneManager::_findVisibleObjects(Ogre::Camera * cam, Ogre::VisibleObjectsBoundsInfo * visibleBounds, bool onlyShadowCasters)  Line 583	C++
 	OgreMain.dll!Ogre::SceneManager::_renderScene(Ogre::Camera * camera, Ogre::Viewport * vp, bool includeOverlays)  Line 1474	C++
 	OgreMain.dll!Ogre::Camera::_renderScene(Ogre::Viewport * vp, bool includeOverlays)  Line 414	C++
 	OgreMain.dll!Ogre::Viewport::update()  Line 219	C++
 	OgreMain.dll!Ogre::RenderTarget::_updateViewport(Ogre::Viewport * viewport, bool updateStatistics)  Line 200	C++
 	OgreMain.dll!Ogre::RenderTarget::_updateAutoUpdatedViewports(bool updateStatistics)  Line 179	C++
 	OgreMain.dll!Ogre::RenderTarget::updateImpl()  Line 155	C++
 	OgreMain.dll!Ogre::RenderTarget::update(bool swap)  Line 614	C++
 	projectz.exe!ZGame::DeferredGraphicsManager::update()  Line 208 + 0x61 bytes	C++
 	projectz.exe!ZGame::GraphicsController::onUpdateDeferredSystems()  Line 342	C++
 	projectz.exe!ZGame::EngineController::run()  Line 543	C++
 	projectz.exe!main(int argc, char * * argv)  Line 94	C++
 	projectz.exe!__tmainCRTStartup()  Line 555 + 0x17 bytes	C
 	kernel32.dll!75fbd0e9() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	ntdll.dll!775116c3() 	
 	ntdll.dll!77511696() 	
My blog here.
Game twitter here
User avatar
ahmedismaiel
OGRE Contributor
OGRE Contributor
Posts: 217
Joined: Wed Jan 25, 2006 11:16 pm
Location: Redmond,WA

Re: DirectX 11 render system - work-in-progress

Post by ahmedismaiel »

did anyone try parallel insight ,when trying to debug our game with d3d11 it crashes on the first present .
http://forums.developer.nvidia.com/devf ... gin#Item_1

let me know what your experience with this tool .i want it to debug the depth buffers (which PIX doesn't do) for my soft particle effect
User avatar
bvanevery
Goblin
Posts: 218
Joined: Wed Feb 28, 2007 4:54 am
Location: Asheville, NC
x 7

Re: DirectX 11 render system - work-in-progress

Post by bvanevery »

Is the DX11 renderer not even theoretically buildable on MinGW? MinGW links against the VC6 runtime and I don't believe MS supports that for DX11. There is some ancient advice in the Build FAQ pertaining to DX9 and "extras" DXSDK libraries from 2004. My build of Ogre 1.8.0RC1 fails at final link, missing security_cookie and 2 other symbols. If there is a workaround, what needs to be done?
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: DirectX 11 render system - work-in-progress

Post by CABAListic »

A year ago or so I added some hacks that allowed DX9 and DX11 rendersystems to compile with MinGW. Might be that those hacks broke with the continued development of the DX11 rendersystem. Anyway, even though it did compile back then, it didn't really work, so yeah, I think MinGW and DX11 don't really mix well.
User avatar
bvanevery
Goblin
Posts: 218
Joined: Wed Feb 28, 2007 4:54 am
Location: Asheville, NC
x 7

Re: DirectX 11 render system - work-in-progress

Post by bvanevery »

What did you do? I've been Googling about "mingw security_cookie" and came up with an article in the MS Knowledgebase. It seems to say that linking with bufferoverflowU.lib might solve the problem. Did you try that or something else? I haven't tried anything myself yet. Hmm, unfortunately it looks like this bufferoverflowU.lib is a historical SDK component, not a current one. I wonder if this lib could be resurrected from somewhere, and if it would still work with the venerable mingw VC6 runtime linkage strategy.
Last edited by bvanevery on Sat Jan 07, 2012 2:45 am, edited 1 time in total.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: DirectX 11 render system - work-in-progress

Post by CABAListic »

Actually I implemented the missing functions as stubs (or in one case with a call to a MinGW equivalent), and I do believe security_cookie was one of those stubs, so it's kind of strange that it fails on those again. If I get the chance, I'll take another shot at it.
This is, of course, not much more than a really primitive hack. So if linking to that library solves the problem, it's definitely the better solution.
User avatar
bvanevery
Goblin
Posts: 218
Joined: Wed Feb 28, 2007 4:54 am
Location: Asheville, NC
x 7

Re: DirectX 11 render system - work-in-progress

Post by bvanevery »

Seemingly it is possible to customize gcc's "specs" file to get mingw to build with a C runtime other than msvcrt.dll. No idea if it is advisable; it is surely not a common practice. Nowadays the more recent MS C runtimes carry the code that makes security_cookie actually work. msvcrt.dll is really ancient, it doesn't even support C99 stuff.

The MinGW developer list discussed versioning of different MS C runtimes as far back as 2004. It seems to have gotten a cool reception because the number of things that would be affected is not trivial. Also there are some potential GPL license wonkery issues. It may be possible to get this to work if one is willing to recompile a lot of other MinGW components. Or maybe that's overkill, I can't really tell.

Clang has a -fmsc-version flag which changes what CRT is used. Also there's no license wonkery. However the MS extensions may be incomplete, and I'm not sure if Clang can reliably build windows.h. It's another way of trying to build Ogre with something other than MSVC.
User avatar
Eugene
OGRE Team Member
OGRE Team Member
Posts: 185
Joined: Mon Mar 24, 2008 4:54 pm
Location: Kraków, Poland
x 41

Re: DirectX 11 render system - work-in-progress

Post by Eugene »

Hello, all.

As part of my efforts to port Ogre to Windows 8 Metro-style platform I tweaked Direct3D11 Render System to be conditionally compiled as Direct3D11.1.
Some interfaces were upgraded to their next versions, but in almost all other aspects Direct3D11.1 does not differs from Direct3D11.

Here is the topic that is dedicated to Win8 port:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=69209

Here are repositories with port itself and ported dependencies:
https://bitbucket.org/eugene_gff/ogre-winrt
https://bitbucket.org/eugene_gff/ogre-d ... cies-winrt

Port is done as separate OGRE_BUILD_PLATFORM_WINRT, it is already functional, building as OGRE_BUILD_PLATFORM_WIN32 is not broken.
There are still issues with Direct3D11 Render System[s], such as missing ability to resize swapchain on the fly (very important for WinRT as devices can be rotated), or memory leaks[/s] as well as not yet removed d3dcompiler.dll dependency.

I`ll continue to fix such issues in my fork, and I`m interested in merging my work into the trunk.

What do you think about all of this?
Last edited by Eugene on Wed Jun 13, 2012 10:01 pm, edited 2 times in total.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: DirectX 11 render system - work-in-progress

Post by Assaf Raman »

Nice, good work.
What versions of windows does d3d11.1 is supported on?
Watch out for my OGRE related tweets here.
User avatar
Eugene
OGRE Team Member
OGRE Team Member
Posts: 185
Joined: Mon Mar 24, 2008 4:54 pm
Location: Kraków, Poland
x 41

Re: DirectX 11 render system - work-in-progress

Post by Eugene »

Assaf Raman wrote:Nice, good work.
What versions of windows does d3d11.1 is supported on?
Windows 8, as D3D11.1 is essentially D3D11 + Win8 Metro App support (ICoreWindow instead of HWND)
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: DirectX 11 render system - work-in-progress

Post by Assaf Raman »

Well, I don't have a windows 8 computer... I guess I can create a virtual machine for it or the sort...
Watch out for my OGRE related tweets here.
Post Reply