yup has... and from what i've been told the demo is more unstable than the full product - as i've not used the full thing since patch2 i can't really comment.
i'm trying to find the time when i can actually have my system down long enough to re-install the OS so the trial starts again. Problem is finding the time ... well right now the new path is going along the lines of rather than editing and wanting the user to recreate the render environment - it'll do it within the function, this should prevent the problems no?
perhaps i should send Lee the code and ask for his help
i don't normally like to do this but ... thats the actual function, just without the external.
Now the main pointers are defined at the top of the DLL as they'll be global for the needs - so its obvious where its comming from.
// get current desktop display mode
D3DDISPLAYMODE d3ddm;
// check to make sure we can get current data ... if not let the user know
if( FAILED( g_pD3D->GetAdapterDisplayMode( D3DADAPTER_DEFAULT, &d3ddm ) ) )
{
MessageBox(NULL,"Direct3D Device Failed to Initilise","Error",MB_OK);
}
// make sure the presets are declared and place in a pointer
D3DPRESENT_PARAMETERS d3dpp;
ZeroMemory( &d3dpp, sizeof( d3dpp ) );
//d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD; // remarked because DarkBasic may already have done this
d3dpp.BackBufferFormat = d3ddm.Format;
d3dpp.MultiSampleType = D3DMULTISAMPLE_2_SAMPLES;
i'm pretty sure whats happening is the pointers are overwriting DBpro's render instance ... i'm not entirely sure.
well have fun becuase over the next day i'm working on my MFC stuff
Anata aru kowagaru no watashi! 
