Some thoughts on 4k competition rules
category: code [glöplog]
And losing D3DX is not a death sentence for D3D9 intros.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb153295%28v=vs.85%29.aspx
So smart coders can use the ms product and be happy.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb153295%28v=vs.85%29.aspx
So smart coders can use the ms product and be happy.
oops thats for C#, scratch that
So if we allow a so-called "demoscene-toolkit" to be used to make 4ks... we should just go ahead and allow 4ks that require the unreal engine to be installed as well. Because... you know... it's ok.
Quote:
The platform that is generally agreed on for intro compos is and has been a dynamic thing
Certainly. But it has been "The latest Windows with the latest DirectX End-User Runtime and up-to-date drivers" for 7 years now. As long as this setup still makes sense, I see no reason to abandon it.
If it should happen that this setup becomes inadequate (new must-have features not supported by old shader compiler), cumbersome to use for the developer (new Windows SDK doesn't work at all with old D3DX) or cumbersome to set up (DirectX Web Installer no longer working), then we need to redefine the platform. It does seem likely that at least one of these conditions will arise eventually.
But I personally don't buy the "deprecated by Microsoft" argument. Since when did we care about what was the official way of doing things? If it works, it works (where "works" means being broadly compatible with machines adhering to the defined target platform). If we always followed official specifications, there would be no such thing as Windows 4k intros in the first place.
Seven:
I can't see a problem with that. The problem is, with windows now we effectively have 3 platforms people are going to be using - xp, 7 and 8. XP is basically 'end of life', and 8 is going to be the default on new PCs… and now d3dx is depreciated and the shader compiler is not part of the windows install. So it's pretty hard to justify d3dx and the shader compiler on windows 8, you're installing non-standard stuff to help make the demos prettier. Because of that some of us at least are suggesting banning those on win8. I'm guessing that most parties will support either 7 or 8 and this is only going to affect people who want to target 8.
At some point you'll presumably want to move on from xp/7, so this is something to bear in mind for the future, basically. It's not so much "drop your current stuff NOW!" as "this looks like a dead end, consider where you're spending your energy".
That was the general idea - I'd like to see that as a separate compo. Otherwise, good luck competing against something iq took 2 weeks to render with your puny realtime shit :D
Quote:
As a 4K coder, I'll throw in my 2 cents... I'd prefer to keep the DirectX dlls installed on the compo machines for at least a few more years.
I can't see a problem with that. The problem is, with windows now we effectively have 3 platforms people are going to be using - xp, 7 and 8. XP is basically 'end of life', and 8 is going to be the default on new PCs… and now d3dx is depreciated and the shader compiler is not part of the windows install. So it's pretty hard to justify d3dx and the shader compiler on windows 8, you're installing non-standard stuff to help make the demos prettier. Because of that some of us at least are suggesting banning those on win8. I'm guessing that most parties will support either 7 or 8 and this is only going to affect people who want to target 8.
At some point you'll presumably want to move on from xp/7, so this is something to bear in mind for the future, basically. It's not so much "drop your current stuff NOW!" as "this looks like a dead end, consider where you're spending your energy".
Quote:
I really don't see the need to remove the realtime limitation. In my opinion it's the most important difference between the demoscene(and games) and other computer artforms. Balancing speed vs visuals has always been part of the scene, optimizing your code is important. Hardware is still getting faster, so we already get more headroom for new things to try every year. I really wouldn't like to compete against such "4k animations". Put them in a different category, as we do with the 4K graphics already. (And not every party has to have all 4K compo variants, of course)
That was the general idea - I'd like to see that as a separate compo. Otherwise, good luck competing against something iq took 2 weeks to render with your puny realtime shit :D
Quote:
Now we have to deal with Win8 and should reevaluate common 4k intros compo rules.
- IMHO D3DX from DX9 can not considered "standard" anymore - therefore we should disallow the usage of it.
- Can dx9 still considered "standard" on current vanilla windows? If not - disallow it.
What the hell is that? I don't see the whole point of this discussion.
The DirectX Runtime June 2010, the one that has been installed on every single compo machine for the past 2 years is installable and workable on a Windows 8 machine. I'm mainly developing on Windows 8 for the past few months, and I'm still using this old runtime for all my dev. Moreover, this runtime will be accessible for a shitload of years because this is the runtime that will still be required by all legacy app that could run on any pre-Win8 and Win8 machine.
So there is absolutely no reason to reevaluate anything about compo rules for 4k . Like Blueberry said, Its not because MSFT says that their will be no more DirectX SDK (and thus runtime) that you can't install a legacy DirectX runtime.
There could be only one issue if you would like to use the latest d3compiler_xx.dll (the one that is shipped with Wiin8 SDK but is also working on Win7), but there is little new features in this new version (apart some optimizations and compute shaders bytecode re-org).
Blueberry: I agree about the "deprecated by Microsoft"-argument, especially when the suggestion is to have everyone use OpenGL instead. Microsoft deprecated OpenGL support on Windows with the release of Vista. But no one suggests disallowing OpenGL productions, because it makes no sense.
Quote:
But maybe if you do your OWN shader compiler to the secret bytecode format, producing carefully packed-size optimized code it could be possible. I know blueberry got the absolutely perfect profile for that job ;)
I don't know if the blob is even the same format that is sent to the IHV compiler, in which case the format should be somewhat obtainable, even if confidential ;)
Isn't the output from the Direct3D shader compiler in the format documented here?
To get rid of some of the redundancy in the bytecode format that KK mentioned, one could design a new bytecode format with less redundancy which is easy to transform to binary Direct3D shader code. For instance, a stack-based format gets rid of most of the register allocation redundancy. For shader-heavy intros (say, more than 1.5k of compressed shader code), this approach could potentially rival shader source in size, even with the overhead of the code to do the code transformation.
As for the compiler, the main trick to obtaining compression-friendly code is to generate the code in a systematic and consistent way (the same constructs always generate the same code) and to do only a minimum of optimization. This also has the benefit of establishing a direct and comprehensible structural relationship between the source code and the binary code, which will give the shader writer more direct control over the end result (which is a very good thing). Coincidentally, this is also the easiest way to write a compiler. :)
Such an approach would not generate particularly efficient code. We will have to rely on the subsequent compilation from the Microsoft shader code to the internal GPU code by the graphics driver to do the heavy optimizations for us. I would expect lots of optimizations to happen at this stage, but they might be tuned to the particular way that the HLSL shader compiler generates code, so code that looks different might end up not being optimized as efficiently.
I don't see why we can't use something like a "standard intro library" that gets installed on every compo-machine with the goal of solving fixing compatibility issues. The intros wouldn't run on PCs that don't have this lib, but those people watch intros on youtube anyway.
I'm guessing that in the future things will get more and more fucked up for size restricted intros and without a lib like this, 4k would be impossible. Programs are generally getting more and more bloated and so are their SDKs, and even if it still enables you to write a 4k demo, you get less bytes to work with.
The lib's goal should be to handle all win/gl/dx/mm api calls and automatic window creation so solbes compatibility issues while it also saves you a few extra bytes and you only have to concentrate on the intro part. It would mostly just be a wrapper around winapi, waveout, opengl+extensions, dx9, dx?? that get distributed with the introlib.
There should be a few helper functions for window creation, that increase compatibility and maybe even support for audio/video recording. The lib could be used for 1k, 4k, 64k and intro/gfx/music. The lib will not write the intro for you and won't include any features that help with content creation, sequencing ect.
I'm guessing that in the future things will get more and more fucked up for size restricted intros and without a lib like this, 4k would be impossible. Programs are generally getting more and more bloated and so are their SDKs, and even if it still enables you to write a 4k demo, you get less bytes to work with.
The lib's goal should be to handle all win/gl/dx/mm api calls and automatic window creation so solbes compatibility issues while it also saves you a few extra bytes and you only have to concentrate on the intro part. It would mostly just be a wrapper around winapi, waveout, opengl+extensions, dx9, dx?? that get distributed with the introlib.
There should be a few helper functions for window creation, that increase compatibility and maybe even support for audio/video recording. The lib could be used for 1k, 4k, 64k and intro/gfx/music. The lib will not write the intro for you and won't include any features that help with content creation, sequencing ect.
Quote:
I for my part would like to see more 4k intros that run on more computers
Then bleeding-edge OpenGL intros that usually only run on half the hardware-capable population isn't the way to go...
And amusing related to this discussion, as the incompatibilities are mostly due to the differences in vendor supplied shader compilers...
mu6k: allow it for 64kb/intro coding and I would fully support that.
Quote:
So it's: "Runs on the compo machine only. In the right configuration. With driver version XYZ. Once." again (I never had at Tseng ET4000 btw). Nice... Even more people that go to youtube to watch demos.there's just no shadercompiler - you have to store binary.
OpenGL/OpenCL is king here atm, because it comes with your driver and has a shader compiler. The implementation might be crap and your profile might not be supported, but chances it will run are pretty good (plus: older demos on newer systems might just work automagically).
Disallowing the MSVC redist (and everything else) sounds funny, but will suck pretty bad and might probably make the executable grow considerably, because you have to code shit (read: the shit it's supposed to do for you) yourself. Most people wouldn't want to go there?
I'm pretty happy with having to install DX9 here. Or having to install nothing (or a newer driver), because it's OGL...
mu6k: that kills the magic a bit though. It's no longer "wow, that's possible in 4K?" but "it's possible in 4k with some help from some additional stuff". Personally I'd rather see 8k become standard than have some 'demo player'.
Although I can see the appeal too. Make the 'player' a VM with a wrapper for the video hardware and make it cross platform and it would be seriously interesting :)
Psycho: is it still the case that the openGL issues are mostly because of nvidia's shitty "anything goes, even if it's against the spec" compiler? That was easily cured by coding on ATI, or at least following the spec ;)
Although I can see the appeal too. Make the 'player' a VM with a wrapper for the video hardware and make it cross platform and it would be seriously interesting :)
Psycho: is it still the case that the openGL issues are mostly because of nvidia's shitty "anything goes, even if it's against the spec" compiler? That was easily cured by coding on ATI, or at least following the spec ;)
raer: I think you misunderstood things.. Storing shaders as *device independent* dx byte code is probably the most future proof and compatible way. In the glsl case you not only have the parser differences between amd and nvidia, but also differences between driver versions, making it more likely that a future driver may break compatibility (for instance because they fixed some sloppyness you accidentially relied on).
psionice: seems like it, but even if you want to it can be hard to follow, and you can easily break compatibility when you bring your nvidia laptop (which of course must be nvidia if your desktop is amd and vice versa) to the party ;)
But TBH I've also encountered incompatibilities in my more tech-pushing dx intros (bugs in nvidia backend compiler - and quite curious ones considering it's only a backend compiler - could be funny twist if they are actually intercepting the d3dx frontend ;)
psionice: seems like it, but even if you want to it can be hard to follow, and you can easily break compatibility when you bring your nvidia laptop (which of course must be nvidia if your desktop is amd and vice versa) to the party ;)
But TBH I've also encountered incompatibilities in my more tech-pushing dx intros (bugs in nvidia backend compiler - and quite curious ones considering it's only a backend compiler - could be funny twist if they are actually intercepting the d3dx frontend ;)
Would dx bytecode really be more future proof? I would have thought it'd be harder to fix any issues with the shaders, and is it not more likely to change in future windows updates than the shader source?
And yeah, there's always going to be some driver compatibility issues, whatever platform you use. I'm currently trying to figure out why my OpenGL ES code works fine on SGX543MP4 but not SGX543MP2 with an older driver version - the platforms are near identical and still the difference is enough to corrupt a texture somewhere.
But if you end up finishing an intro on an nvidia box, ATI provide a shader tool that will highlight errors :) (I seem to recall a setting for the nvidia stuff that enforces strict spec checking too, that would also work). From what I've seen in the past, just remembering that '0' isn't a valid float but '0.' is will fix most issues :D
And yeah, there's always going to be some driver compatibility issues, whatever platform you use. I'm currently trying to figure out why my OpenGL ES code works fine on SGX543MP4 but not SGX543MP2 with an older driver version - the platforms are near identical and still the difference is enough to corrupt a texture somewhere.
But if you end up finishing an intro on an nvidia box, ATI provide a shader tool that will highlight errors :) (I seem to recall a setting for the nvidia stuff that enforces strict spec checking too, that would also work). From what I've seen in the past, just remembering that '0' isn't a valid float but '0.' is will fix most issues :D
Quote:
k then. sounds better, but might be less compressible too...*device independent* dx byte code
Psonice: I only just moved from XP to Win7, and the main reason I bought a new machine was that Win 8 was arriving and for some time it was not clear if you could downgrade to 7 :) I agree with your "At some point you'll presumably want to move on" but that could easily be another 5 years, so I don't see the hurry, and it most likely won't be to Win 8.
That's another reason I think this discussion is premature, Win 8 is only out for a few days. Given the mixed feedback, it could very well become another Vista. Do we really need to change rules if Win 7 is the new XP? As Xoofx wrote, just use the DirectX Runtime June 2010. You can put it in the info file, in the compo machine specs, most gamers will have that installed already etc.
That's another reason I think this discussion is premature, Win 8 is only out for a few days. Given the mixed feedback, it could very well become another Vista. Do we really need to change rules if Win 7 is the new XP? As Xoofx wrote, just use the DirectX Runtime June 2010. You can put it in the info file, in the compo machine specs, most gamers will have that installed already etc.
Seven: true. Maybe it's wise to wait and see, if it is another vista win9 could change things a whole lot. Question is then, will 9 be more like a fixed 8 Pro or more like 8 RT? That will have some major implications, never mind opengl the choice might be mac or linux :D
There's still the question of windows 8 demos though. If somebody wants to write for it, it's the current windows OS and parties should really support the current standard for the newschool compo.
There's still the question of windows 8 demos though. If somebody wants to write for it, it's the current windows OS and parties should really support the current standard for the newschool compo.
raer: MSVC redist has not much practical importance in 64k and most 64k coders already have gone that route.
Seven: I'd suggest March 2008 runtime if it works for you. A bit more buggy, but much, much faster shader compiler, which makes huge difference in raymarching shaders.
Seven: I'd suggest March 2008 runtime if it works for you. A bit more buggy, but much, much faster shader compiler, which makes huge difference in raymarching shaders.
KK: I'm a OpenGl 4K coder, so: NOOOOO!!! I want the DX entries to compete against, but it should be clear to the audience OpenGL alone makes my code far superior already, and looong HLSL compile times drive home that point so nicely! </EvilSeven>
Seriously, use whatever runtime you want, just don't end-of-life a platform because MS says "Jump".
Seriously, use whatever runtime you want, just don't end-of-life a platform because MS says "Jump".
Did anybody have a look at that metro-api? Is it suitable for doing demoscene-stuff with it? Does it have its own dx/3d interface? Can those apps be run on RT (Arm) and x64 systems?
if so: go for it! I want my tile-demos ;)
if so: go for it! I want my tile-demos ;)
@wysiwtf, metro app are only installable from the appstore (apart when you are working on your dev machine), so you could of course publish your demo to the AppStore, but It would have to go through the same kind of validation/process as a submitted game. Apart from that, the available API is Direct3D11 and you get rid of the WinMain/MessageLoop/HWND mess. Also to publish on ARM, there are some policies to respect, mainly that 9.1 level should be supported (he doesn't mean that your application should run in 9.1, but It should at least popup a message and says that 10.0 is required for example).
Late to the party, but vaguely worried about the implications over here, where the compo machine is still whatever we can cobble together . . .
However, what strikes me about this D3DX problem (not saying anything new doubtless) is just a symptom of the larger issue of being tied to an industry making its money off planned obsolescence and proprietary lockdowns which are just getting worse. Yes, the hardware improves in leaps and bounds, but it strikes me that, as the impetus toward Apple-style lockdown seems to increase across the industry, one has to strike a balance between being dictated to by the manufacturers and finding a way to negotiate a critical self-serving response to this problem in general within the scene, something that doesn't seem to have happened so far.
Which is a separate problem than people not producing and watching stuff on YouTube. After all, the format wars are nothing new.
However, what strikes me about this D3DX problem (not saying anything new doubtless) is just a symptom of the larger issue of being tied to an industry making its money off planned obsolescence and proprietary lockdowns which are just getting worse. Yes, the hardware improves in leaps and bounds, but it strikes me that, as the impetus toward Apple-style lockdown seems to increase across the industry, one has to strike a balance between being dictated to by the manufacturers and finding a way to negotiate a critical self-serving response to this problem in general within the scene, something that doesn't seem to have happened so far.
Which is a separate problem than people not producing and watching stuff on YouTube. After all, the format wars are nothing new.
Well - some of you might have noticed that I opened a thread in 2005 - regarding the same issue. Funny - isn't it? I must be some kind of terrible hardliner - I'm soooo sorry for that.
Some history:
BP05 compo orgas opened the box of pandora by allowing D3DX - when it was not even in the dx enduser runtime (they expected it to be there some day, but that took something like a year and the first comment from microsoft was something like "nope D3DX wont become part of the end user runtime" - later this changed).
Let me speculate why that happened (I'm not certain about this and I don't want to blame anyone here) - the top intros 1st & 2nd at BP05 used it - so I guess - somebody asked behind the scenes for it. Just some speculation here - AGAIN I'm not blaming anyone. Just for the record - Assembly 05 did NOT allow D3DX iirc - exactly because that box of pandora thing. Evoke 05 did - and I remember that the compo orgas had a lot of fun getting the proper DLLs...
For a short period of time - I'm not certain about this (could somebody verify/falsify this?) - D3DX was also spread via windows update for WinXP). Good times!
Things changed with Windows Vista and stayed changed till now - Windows provided DX support per default - but no D3DX. It's not that this happened yesterday.
Some history:
BP05 compo orgas opened the box of pandora by allowing D3DX - when it was not even in the dx enduser runtime (they expected it to be there some day, but that took something like a year and the first comment from microsoft was something like "nope D3DX wont become part of the end user runtime" - later this changed).
Let me speculate why that happened (I'm not certain about this and I don't want to blame anyone here) - the top intros 1st & 2nd at BP05 used it - so I guess - somebody asked behind the scenes for it. Just some speculation here - AGAIN I'm not blaming anyone. Just for the record - Assembly 05 did NOT allow D3DX iirc - exactly because that box of pandora thing. Evoke 05 did - and I remember that the compo orgas had a lot of fun getting the proper DLLs...
For a short period of time - I'm not certain about this (could somebody verify/falsify this?) - D3DX was also spread via windows update for WinXP). Good times!
Things changed with Windows Vista and stayed changed till now - Windows provided DX support per default - but no D3DX. It's not that this happened yesterday.
