pouët.net

one sure thing renaming _47.dll to _43.dll works with D3D9 and enable faster compilation. you can also gives the DLLs in your app path and the constraint with Windows SDK and D3D11.1/2 is only for metro apps, so no WIN7.

who's talking about metro apps?

Thinking about this:

Would compo organizers allow intros to target the Windows SDK, requiring d3dcompile_47.dll, implicitly requiring Windows 8.1, but having the d3dcompile_47.dll lying alongside?

If the OS is windows 8.1, the intro runs without that dll.
That dll would be only there, so that consumers can run it on older windows versions.

I guess this won't break any compo rules regarding size limitations, but I guess this is a grey zone.

I'd like to hear the opinion of some PC compo orgas.

I guess the right thing for 16k and larger is to dynamically load what's available of _47 and _43 (since they seem interoperable to the features supported by _43) - and ask for the dx runtime (ie the nice official web installer) to be installed otherwise.
Wonder how much the _43/_47 loader would take (as an option) in crinkler's dll loader, but otherwise it seems too much of a burden for 4k.

So for now it's probably up to the compo organizers if we should make the 4ks easily forward compatible (not requiring dx runtime installer on win8) by allowing using _47 at the expense of slightly less convenient dll installation on win7.

Well, the simplest option would probably be to supply two exe's, one linked to _43, the other to _47?

intro_1280x800_win7.exe
intro_1280x800_win81.exe
intro_1366x768_win7.exe
intro_1366x768_win81.exe
intro_1920x1080_win7.exe
intro_1920x1080_win81.exe
intro_1920x1200_win7.exe
intro_1920x1200_win81.exe
;)
But yeah, you are probably right.

Afaik crinkler can already re-route calls from one dll to another, so building both exes is not much of a burden.

Still, I would prefer distributing only one exe plus the _47.dll together in the same directory. A win 8.1 pc can run the intro without that .dll in the same directory (compo orgas already do some cleanup while preparing), and earlier windows versions would require that dll.

I don't really like the idea of targeting the intro only at the very latest OS version - normally it'd be ok, but in this case the OS is looking like a bit of a vista (it's not exactly taking off).

But then again, doing so and including the DLL for compatibility - is it any different from including a youtube link because you targeted the latest high-end GPU almost nobody owns? I'd definitely take a 4k with a DLL that's only used for backwards compatibility over a youtube link :)

Half the games still run on DX9 and install the redist anyway.

Are you suggesting that intros should do the same with _47.dll as well?

Well, it totally depends on the compo pc. If it's Win 8.1 than I would consider the usage of the _47.dll implicitly as OK.

If it's a Windows < 8.1 machine, well than things are a bit different and it's up to the compo orgas.

My personal opinion:
I don't like the idea of having the DLL in the intro directory - since we would than have to check checksums to prevent obvious cheating possibilities. It's more probable that IFF the compo PC is a Windows 7 PC - that for forward compatibility reasons - I would ensure the _47.dll is globally available on the machine (both 32 bit and 64 bit).

Anyways: Having a backwards compatible version - maybe with precompiled shaders, would be nice.

Checking for the DLL is also OK imho. Why not?

Well - should be even OK for 8k, you have plenty of space there. ;)

Then the compo orgas could safely delete that dll from the intro folder. It should just work then.



Well the easiest way to provide a backwards compatible version is to simply deploy that dll...

Yes! tUM is doing it right in my opinion :) This is the feedback that I wanted to see. I think it's a great start.

The next step would be to offer Windows 8.1 as a platform and make sibling dlls count for the file size again, i guess...

I just found out that the d3dcompiler_47.dll depends on the WinRT dlls, meaning that it won't work on lower windows versions.

Windows 8.1 doesn't ship with d3dcompiler_46.dll, the next-lower version would be d3dcompiler_43.dll. I checked with depends.exe, d3dcompiler_46.dll does not require WinRT.

Sadly this means, that 4k and 8k intro makers targetting Windows 8 should definitely provide separate binaries for lower windows versions. It's not too hard, crinkler has /REPLACEDLL for that. It's just uncomfortable.

(tl;dr: d3dx is deprecated, to efficiently compile hlsl you need d3dcompiler_47.dll. That dll is not backwards compatible for win 7. Intro makers should provide win7 and win8 binaries.)

WHAAATTT??? d3dcompiler_47.dll is included in VS 2013. file info says "for redistribution" and it works just FINE on windows 7.

am i missing something else you didn't mention?

i´m with las here - funnily, this is the first reason why 8k actually can make sense: dual-platforming for win7 and win8 ;D

Yesterday I gave my 8k for testing to a friend running win7, that dll was residing together with the exe. Crinkler failed to load it (message box saying "d3dcompiler_47"). Without crinkler the usual "application configuration error" dialog popped up.
I had to replace the d3dcompiler_47.dll with d3dcompiler_46.dll and rename it. Only then would it run.

I investigated how much it would cost to implement a DLL fallback mechanism in the Crinkler importer.

It will be 7 or 8 bytes of code plus the extra DLL name. Both of these will be compressed, so in practice, where the DLL names are very similar, it will probably be in the order of 10-15 bytes for a fallback. That ought to be small enough not to worry about it even for a 4k. :)

No promises yet, but it seems viable.

That would be awesome Blueberry! Yay for compatible intros :)