I've haven't looked at DirectX since the DX9 era. Is it possible to make DX11/12 applications without having to also make them UWP applications?
I'm a little concerned about the overhead of UWP-- for fun, I made an empty application, and I noticed it uses ~30MB just to draw a blank window.
I'm guessing by "WUP" you mean the Universal Windows Platform (UWP). Direct3D 11 is supported for Win32 classic desktop apps on Windows 7, Windows Vista SP2, Windows 8.x, and Windows 10. Direct3D 12 is supported for Win32 classic desktop apps on Windows 10. Both are also supported for UWP and Xbox One.
To catch up on the modern story for DirectX, you should see: MSDN, Where is the DirectX SDK (2015 Edition)?, and Getting Started with Direct3D 11, as well as the DirectX Tool Kit tutorials tutorials
There are three basic appmodels for UWP: XAML, XAML+DirectX, and DirectX (i.e. no XAML). A basic DirectX app for Direct3D 11 with just a swap chain and device has an EXE of about 100 KB as an x86 application in Release mode. A DirectX+XAML 'empty' app is around 347 KB.
UPDATED: The basic DirectX app for Direct3D 11 as Release mode for x86 has a RAM footprint of around 6.1 MB in full-screen mode. A DirectX+XAML 'empty' app in Release mode for x86 is 11.2 MB. That's pretty good since a 1920 x 1080 BGRA32 render target texture is 8 MB of VRAM.
Related
I'm using Delphi 10.0 Seattle and trying to use the rear cameras's light on a Lenovo Thinkpad tablet running Windows 10 Pro. I am using TCameraComponent.
I tried using CameraComponent.TorchMode := TTorchMode.ModeOn from FMX.Media, but it raises an exception saying that the device has no torch.
Anyone know why this happens, and if there is some way to access this light/flash?
FMX in Delphi 10.0 Seattle does not implement either Flash or Torch functionality at all on Windows. It is only implemented on OSX, iOS, and Android.
You will have to resort to using Windows-specific APIs, or even manufacturer-specific APIs, to access light/torch functionality. For example, there are FlashControl and TorchControl classes in the Windows UWP API.
Are there any problems with programs that are compiled with Delphi 2010, using Rave reports (no database connection) running on Windows 10?
In principle, there's no reason why a program compiled with Delphi 2010 will not work perfectly well on Windows 10. Indeed, a program compiled with any 32 bit version of Delphi (Delphi 2 or later) can, in principle, be executed on Windows 10.
The usual caveats apply though. You have to make sure that your code respects features like UAC. So don't attempt to write to HKLM, system directories, etc. as standard user.
As a broad guideline, if your program executes on Windows 8.1, you can expect it to execute on Windows 10 also.
So, in summary, you should be perfectly capable of producing a program that runs on Windows 10 using Delphi 2010. However, it's impossible for anyone to tell you definitively that your program will run because only you know the full details of how your program is implemented. You should test your program on each new operating system as it is released, if not before it is released.
I'm not sure, but the internal Kernel ID from Windows is set from 6.x (Windows Vista - Windows 8.1) to 10.0 (Windows 10) so this can be a problem.
I am running Windows 7. When I use DxDiag, it shows the version as 11.
When I use Visual Studio 2012 which can access Windows API, it can run the code with feature level D3D_FEATURE_LEVEL_11_1
So I agot confused, what is the exact version of my DirectX version?
There are a number of confounding factors at work here, so let's take them one at a time:
DXDIAG is part of the OS along with the DirectX Runtime but is also manually updated for that string, so it is often less than detailed/accurate about reporting "DirectX" version. For Windows Vista SP1 it doesn't say "DirectX 10.1" and says "DirectX 10". Similarly, with both Windows 8 and Windows 7 SP 1 + KB2670838 installed it still says "DirectX 11" and not "DirectX 11.1". On Windows 8.1 it still says "DirectX 11" and not "DirectX 11.2". In short, DXDIAG is not your best option for technical details like this. You could try using the latest version of dxcapsviewer in the Windows 8.1 SDK which is a bit more sophisticated in how it check things, but still needs manually updating over time so it currently says nothing about Windows 10 features like DX 11.3 or DX 12.
If you pass NULL for pFeatureLevels to D3DCreateDevice even on Windows 8.x, you will still not get D3D_FEATURE_LEVEL_11_1. This is for backcompat reasons and ensures the behavior doesn't change where NULL gets you 9.1 - 11.0. You have to manually list the 11.1 value in the array to get it--assuming the system+driver combo actually supports it. Note that if you do include 11.1 in the array, the call will fail with E_INVALIDARG on Windows Vista SP2, Windows 7 RTM, or Windows 7 SP1 without KB2670838.
Windows 7 SP1 + KB2670838 provides the DirectX 11.1 API, but does not support D3D_FEATURE_LEVEL_11_1 or any of the new optional hardware features because it doesn't include support for the new WDDM 1.2 driver model. You have to be using Windows 8 or later to get D3D_FEATURE_LEVEL_11_1 with a WDDM 1.2 driver and appropriate hardware. See Microsoft Docs
In general, the proper way to handle all this for Windows desktop applications is:
D3D_FEATURE_LEVEL lvl[] = {
D3D_FEATURE_LEVEL_11_1, D3D_FEATURE_LEVEL_11_0,
D3D_FEATURE_LEVEL_10_1, D3D_FEATURE_LEVEL_10_0,
D3D_FEATURE_LEVEL_9_3, D3D_FEATURE_LEVEL_9_2, D3D_FEATURE_LEVEL_9_1
};
DWORD createDeviceFlags = 0;
#ifdef _DEBUG
createDeviceFlags |= D3D11_CREATE_DEVICE_DEBUG;
#endif
ID3D11Device* pDevice = nullptr;
ID3D11DeviceContext* pContext = nullptr;
D3D_FEATURE_LEVEL fl;
HRESULT hr = D3D11CreateDevice( nullptr, D3D_DRIVER_TYPE_HARDWARE, nullptr,
createDeviceFlags, lvl, _countof(lvl),
D3D11_SDK_VERSION, &pDevice, &fl, &pContext );
if ( hr == E_INVALIDARG )
{
hr = D3D11CreateDevice( nullptr, D3D_DRIVER_TYPE_HARDWARE, nullptr,
createDeviceFlags, &lvl[1], _countof(lvl)-1,
D3D11_SDK_VERSION, &pDevice, &fl, &pContext );
}
if (FAILED(hr))
...
Then to detect support for Direct3D 11.1, you see if you can obtain the Direct3D 11.1 interfaces:
ID3D11Device1* pDevice1 = nullptr;
ID3D11DeviceContext1* pContext1 = nullptr;
hr = pDevice->QueryInterface( __uuidof( ID3D11Device1 ),
reinterpret_cast<void**>( &pDevice1 ) );
if ( SUCCEEDED(hr) )
{
// DirectX 11.1 is present, otherwise only DirectX 11.0
(void)pContext->QueryInterface( __uuidof( ID3D11DeviceContext1 ),
reinterpret_cast<void**>( &pContext1 ) );
}
Don't make assumptions based on Direct3D Feature Level what version of DirectX is installed or vice-versa.
Windows 8 Store apps can assume that DirectX 11.1 is present, but can't assume any particular Direct3D Feature Level (although 9.1 is the minimum you'll ever see).
Windows 8.1 Store apps can assume DirectX 11.2 is present, but again can't assume anything about Direct3D Feature Level.
Windows phone 8.0 apps can assume DirectX 11.0 is present and the devices only support 9.3.
Windows phone 8.1 apps can assume DirectX 11.1 is present and the devices only support 9.3.
Xbox One apps can assume DirectX 11.1 is present. Exclusive apps can assume FL 11.1 is present. Shared apps have to use FL 10.0.
See this post for details on the various nuances of device creation and DirectX 11.x version detection.
See this post and this one for important notes about DirectX 11.1 on Windows 7.
DirectX Feature Levels
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876%28v=vs.85%29.aspx
A feature level is a well defined set of GPU functionality.
Your DirectX version is 11, but depending on your hardware (GPU) you might get feature level 11_1. If your friend down the street has Windows 8.1 and a supporting graphics card, they might have 11.2 features.
Although from what it sounds like, you have at least some 11.1 features available to you.
As said before: Run dxdiag -> go to display -> check driver model. If you have WDDM 1.3 than DirectX 11.2 is installed in your system, if you have WDDM 1.2 than you have DirectX 11.1.
https://walbourn.github.io/directx-11-1-and-windows-7-update/ (http://blogs.msdn.com/b/chuckw/archive/2013/02/26/directx-11-1-and-windows-7-update.aspx)
DXDIAG: Even after applying KB 2670838 to Windows 7 SP1, DXDIAG will still report it as "DirectX 11".
When in doubt, I would suggest relying on the feature level returned from CreateDevice (et al) to be correct.
I downloaded the trial version of Delphi XE7.
After successfully compiling and running some demos on a a virtual device, I connected a Galaxy Tab 3 P5200 through the USB cable.
When I compile and run an application, it is correctly deployed to the device, but when it starts a black screen appears with the following message:
Application does not support this device
In the Delphi XE7 datasheet there is a small box with the "Supported Deployment Platforms" ... for Android they say that an ARMv7 device with NEON support is required. The Galaxy 3 P5200 has an Intel Atom CPU Z2560 ... so Delphi XE7 simply cannot build applications for this device ...
I don't know if you still have this problem but I'll answer it anyways since this problem might occur to other people as it happened with me.
I was able to solve this issue following this:
Running Delphi Applications on Android Intel
From what I could understand, Firemonkey tries to inject code into the application as a some sort of test, and by doing so it uses both mips and x86 architecture, and those are not supported by Intel Atom processors...
Galaxy Tab 3 uses an Intel processor, so I'm sure this will work for you.
In the IDE, open the Deployment Manager (Project > Deployment), and locate the following entry:
After doing so, clean and re-build your project, the application should work just fine.
You can read more about it on Embarcadero's Wiki.
I searched around but I couldn't find a straight answer to these questions, only bits and pieces: if I install windows seven x64,
1 - will I be able to use delphi 2007+ as I'm used to aka start it, code in it, debug in it, compile in it ? I've seen the debugger issue and the hex edit workaround.
2 - will my application compiled in that environnement work on 32 bit versions of windows ?
3 - will my application I compiled with delphi on 32 bit windows work this 64 bit version ?
(of course all this is assuming "normal" applications as-in I don't expect things to work if I'm playing with pointers expecting them to be 32 bits long, obviously)
The overall question of this would be, as someone who is moving to windows seven 64 bits, will I be able to/should I use this as my main delphi developpement platform or will i be better off keeping a 32 bit boot for delphi dev ?
Thanks to anyone who can give me a clue about this
As Mason Wheeler stated, there's a problem with the 2007/2009 debugger and 64-bit platforms but it can easily be fixed.
I'm using D2007 (with this fix) on Windows 7 64-bit on a daily basis and it works just great.
There is now a hotfix for this.
No idea about Windows 7 64 bit version, but I have been using Delphi 4, 5, 2007 and 2009 for nearly a year now on Windows XP 64 bit, and given the effort Microsoft spends on backwards compatibility I don't see why things should be very different on Windows 7. This answers your last question - no need to keep a separate partition. Use virtualization for running things on a 32 bit system. Windows 7 does AFAIK offer you a virtualized Windows XP subsystem - at no cost, but you may need to download it separately.
Re 2. and 3.: The OS an application is compiled on does not matter for the deployment, as long as the compilation itself works. I have only ever been compiling 16 bit Delphi programs on 32 bit Windows versions, without problems. You should however always test on clean installations of your target OS versions, as a developer PC is sufficiently different from a user PC to not assume that everything will just work. This however is general advise, and has nothing to do with a 64 bit OS.
Your Delphi programs will run on a 32 bit layer (WOW64 - Windows on Windows 64) of Windows 64 bit which is close enough to the real 32 bit OS that you do not need to care about it, unless you work very closely with the lower system level.
I was doing some work on Delphi 2007 under Windows 7 64-bit yesterday, and it was a disaster. Every time I'd leave the program while debugging, either by quitting out normally or by stopping the debugger, it would raise an assertion failure that I couldn't get out of, bringing down the entire IDE. (This never happened under XP.) Apparently the WOW64 emulator isn't quite as stable as it ought to be... :(
If you're going to try to work on Windows 7 64-bit, I'd strongly recommend upgrading to Delphi 2010, which was built specifically with Windows 7 compliance in mind. If that's not an option, then at least install a VM with XP on it for your dev work.
Answers are:
1. Yes - With the workaround for the debugger issue
2. Yes - Delphi 2007 (native) will only build 32 bit applications
3. Yes - Unless it's a Device Driver or low-level service
First apply the patch as mentioned on Olaf's Blog. This fixes the debugger exit error.
Second, Install Windows XP Mode, which is a fully clean (and legal) windows XP 32bit virtual machine.
Compile application on Windows 7 64bit. Install onto the virtual machine. It should just work. Rinse, lather and repeat for other applications you are developing.
XP Mode is available to all owners of Windows 7 Professional and Ultimate editions. Don't know about corporate editions.
This is what I'm currently using for development as I had to perform an emergency OSectomy of a Macbook Pro
I run Delphi 2007 on Windows 7 Professional 64 bit and it was fine for a bit until a patch Tuesday a while ago. The IDE would die after throwing the debug error (SetThreadContext failed). I applied the patch found at http://cc.embarcadero.com/item/27521 and no more problems.
HTH. YMMV.
Doug
FYI, I am running Delphi 7 on Win7 64-bit. The trick to run this version is to NOT install to the Program Files(x86) folder - instead, install to something like C:\Delphi7. Been working with it this way for about a month now with a pretty heavy development load and it works great!