Some thoughts on 4k competition rules
category: code [glöplog]
Quote:
And MSVCRT is btw. almost _never_ allowed in intro compos.
Just to be precise - _current_ MSVCRTs are almost never allowed.
Quote:
Nobody likes it if you recommend to take away their toys.
...
I'm still all in for exclusion.
Yes, thank you, as a D3D developer, let me play with my toy please. Probably at next party, we wil setup some segregation rules, we will built a big wall that separate OpenGL coders from D3D coders, what a wonderful way to enjoy together the same passion... :(
Well, more software rendered prods using D3D9 as a rendering frontend ain't a bad idea....=D
Similar discussions have taken place so many times, like the DOS->Windows switch or OCS/AGA. When major parties stop supporting the old option and when computers can't even be bought with it the scene will eventually go with the mainstream. So, in hindsight, all this talk about supporting some extra libs deprecated by The Man is in vain.
mudlord: Probably GDI+ would be simpler way of getting your bytes to the screen.
Marq: Only that this time BOTH legacy and current libs are affected.
sø dos4gw is allowed now?
Quote:
Well we can simply conclude: The final decision wont be made here.
I think we can conclude a lot more. Or at least summarize. Let me try (knowing full well that I am of course as biased as anyone):
The de-facto standard platform for intro coding has been changing through the years. For the purpose of this discussion, the last major change happened back in 2005, around the time when shaders started to get popular. Breakpoint 2005 decided to allow the intros to depend on d3dx9_24.dll - a choice that was met by many objections, including:
1. This is not the way we usually do this.
2. It requires downloading the DirectX SDK, which is not a standard consumer install. A 4k requiring a non-standard several-megabyte DLL is not a 4k.
3. D3DX contains some pretty wild stuff - mesh manipulation, ray/mesh intersection etc - that are usually not considered part of a basic 3D hardware API.
Eventually, D3DX became generally accepted, at least by the people writing the compo rules - and the intros. :)
Why that happened is necessarily speculation, but some plausible reasons are:
1. Other parties did it, and the results were awesome.
2. Microsoft changed the distribution model of D3DX, so it became part of the DirectX End-User Runtime - a standard install.
3. D3DX contains some essential functionality that was left out of Direct3D when compared to OpenGL: shader compilation, matrix stack.
Hardware features and Windows version have both changed several times since then, but the basic formula "Latest Windows with latest DirectX End-User Runtime and latest graphics driver" for describing the platform still holds.
For some reason, Microsoft decided never to include the DirectX End-User Runtime as part of the standard Windows Update, so it has always been a manual install, and this has been a persistent controversy. This is in contrast to OpenGL, which is (usually) updated by Windows Update as part of the graphics driver. It is also generally more acceptable to ask people to update their graphics driver than to download some (however official) Microsoft runtime.
Now, Microsoft has decided to deprecate the D3DX DLLs, the DirectX End-User Runtime and the DirectX SDK. The new Windows SDK contains the necessary material for Direct3D development, but applications that need runtime shader compilation need to include the shader compiler DLL in their distribution. The DirectX End-User Runtime can still be installed for the purpose of old software that requires it.
This discussion seems to be not just about whether to keep the current de-facto platform or to move on to something that allows us to utilize modern features better. There are, as far as I see, three suggestions on the table, as to how compo rules could develop:
1. Ban D3DX because it is deprecated by Microsoft (the original suggestion by las). This will make most existing D3D-based 4k intros ineligible for the compo, and will require all new D3D-based intros to use binary shader code and implement their own matrix stack (if needed).
2. Keep the current rules. New intros developed using the existing DirectX SDK will work fine. Intros that are developed using the new SDK or need new features of the shader compiler will need to use binary code.
3. Allow intros to use the newest (or some older) shader compiler DLL from the Windows SDK. This will enable all intros, Direct3D as well as OpenGL, to use all features of the hardware and to be developed using new development tools, but we might have trouble explaining to anyone who have not participated in this discussion why we call it a 4k when it comes with a several-megabyte DLL.
There you go - a summary from the point of view of a D3DX user. :)
Or 4. everyone goes OpenGL!
I think 2+4 is the most probable way of how things will evolve.
I'm rooting for 2, monopoly isn't good even with an open spec (not that the wold revolves around 4ks)
msqrt: What I meant to say is that 2 is current state and it probably will stay, but MS not including updated compiler in raw system will inevitably lead to 4 in long term when more fancy stuff evolves and OpenGL goes way beyond DX11 (which is latest DX supported by June 2010 release).
2 + 1 for me, and eventually 4 unless things change.
Really we have 2 PC platforms now, we have win8 (current/future platform) and xp/7 (legacy).
Although xp and 7 are now officially legacy systems, in reality they're going to be mainstream for a few years at least, so there's no point in dropping support for them now - so keep the current rules for these systems.
On 8 I just don't think it makes sense to start allowing extra DLLs with 4Ks, and it doesn't make sense to require installation of a depreciated runtime. So drop d3dx and don't allow the compiler dll on win 8. If you want to target that platform, find a way :)
Longer term, xp/7 are going to drop off the map. Hopefully by then the situation will change, and the dlls will be part of the OS or there will be some replacement. If not, it'll have to be openGL.
Really we have 2 PC platforms now, we have win8 (current/future platform) and xp/7 (legacy).
Although xp and 7 are now officially legacy systems, in reality they're going to be mainstream for a few years at least, so there's no point in dropping support for them now - so keep the current rules for these systems.
On 8 I just don't think it makes sense to start allowing extra DLLs with 4Ks, and it doesn't make sense to require installation of a depreciated runtime. So drop d3dx and don't allow the compiler dll on win 8. If you want to target that platform, find a way :)
Longer term, xp/7 are going to drop off the map. Hopefully by then the situation will change, and the dlls will be part of the OS or there will be some replacement. If not, it'll have to be openGL.
An from my side kind of acceptable (not really happy with it - but better a bad compromise than nothing) approach could be:
2.b) Allow D3DX but enforce its usage to be stated on the beamslides and the voting system (this should have been done long ago - as I already proposed that in 2005 as a compromise iirc).
This could even be automated by just showing which DLLs the intro imports - this is simple as long the intro uses crinkler (at least you can figure out quite easy which DLLs get imported by the importer stub using crinkler /RECOMPRESS /REPORT and parse the report) - if it does otherwise the compo orgas could have some fun. Sure you can circumvent that approach - but it will cost you some size - maybe a different approach for a dependency check could be more bullet proof (If you have one to simplify this process tell us).
Partymeister has encouraged the users to show what they use for a long time - the correctness of this information was almost never checked - resulting in people having fun clicking all of the checkboxes and stuff. Might be a good start to clearly state that the orgas reserve the right to disqualify a production with false or incomplete information on it's dependencies. (If not already happening)
With 2.b) blueberry can release the killer intro[s] he certainly has in the pipeline.
So if one goes for 2.b) - keep in mind that can only be a temporary solution.
I would clearly prefer to see 1. happening in the not too far away future (e.g. 0.5 year transition time).
3.) Is out of the question for me.
This surely has it's consequences for 4k (if you want most current shaders with DX - you have to go with binary than, but you can still give OpenGL 4.X a try - so well not that much of a technical evolution stopper) and also consequences for 64k (well storing HLSL shader binary seems to be not that much of a problem here - some groups do that already).
Besides that:
I find parsec a pretty bad example for "good D3DX" usage - from what I know they only generate some simple primitives with it and use the spline functions, iirc the shaders were still stored in binary back than - and there was no crinkler for the masses. Plus: Even the compatible exe does not run here.
There are also some pretty neat intros without D3DX (check out this years asm top 2 4k intros - and revisions first place 4k) - the argument by example seems to be kind of "invalid" to me.
2.b) Allow D3DX but enforce its usage to be stated on the beamslides and the voting system (this should have been done long ago - as I already proposed that in 2005 as a compromise iirc).
This could even be automated by just showing which DLLs the intro imports - this is simple as long the intro uses crinkler (at least you can figure out quite easy which DLLs get imported by the importer stub using crinkler /RECOMPRESS /REPORT and parse the report) - if it does otherwise the compo orgas could have some fun. Sure you can circumvent that approach - but it will cost you some size - maybe a different approach for a dependency check could be more bullet proof (If you have one to simplify this process tell us).
Partymeister has encouraged the users to show what they use for a long time - the correctness of this information was almost never checked - resulting in people having fun clicking all of the checkboxes and stuff. Might be a good start to clearly state that the orgas reserve the right to disqualify a production with false or incomplete information on it's dependencies. (If not already happening)
With 2.b) blueberry can release the killer intro[s] he certainly has in the pipeline.
So if one goes for 2.b) - keep in mind that can only be a temporary solution.
I would clearly prefer to see 1. happening in the not too far away future (e.g. 0.5 year transition time).
3.) Is out of the question for me.
This surely has it's consequences for 4k (if you want most current shaders with DX - you have to go with binary than, but you can still give OpenGL 4.X a try - so well not that much of a technical evolution stopper) and also consequences for 64k (well storing HLSL shader binary seems to be not that much of a problem here - some groups do that already).
Besides that:
I find parsec a pretty bad example for "good D3DX" usage - from what I know they only generate some simple primitives with it and use the spline functions, iirc the shaders were still stored in binary back than - and there was no crinkler for the masses. Plus: Even the compatible exe does not run here.
There are also some pretty neat intros without D3DX (check out this years asm top 2 4k intros - and revisions first place 4k) - the argument by example seems to be kind of "invalid" to me.
Las, do you think we have that much abundance of prods that we need to arbitrarily add rules to disqualify some of them?
They won't be disqualified if this is well known plenty in advance (0.5 years is way too quick I think - consider all the projects that are half-done and put on the shelf for a while.. it'd be shit to come back to your killer entry and find it's no longer acceptable..) Plus it's not good to tell people the stuff they've been working on for ages is no longer acceptable, and they have to start again. It's OK to tell them the stuff they've been using isn't going to be good forever and to start planning though.
It's not really a good outcome if we lose some prods, but it's also not a good outcome if 4k becomes 4k + 4mb dll + a huge old install for some archaic runtime that got depreciated years back.
It's not really a good outcome if we lose some prods, but it's also not a good outcome if 4k becomes 4k + 4mb dll + a huge old install for some archaic runtime that got depreciated years back.
as a party organizer i waaaay prefer solution 2b as outlined by las for a very simple reason: it ensures that people can do cool productions and submit them to my party. It is simply not the case that smaller parties (TRSAC is 100-120 people) can afford to have very strict rules that might ensure a more "fair" competition but leave it out of range of some people. It is not a question of a fair or unfair compo, its the question of an unfair compo or no compo :)
The best solution (for party organizers, not for coders, I know nothing about that) is to let people judge for themselves within a broad framework - I *know* that what randomSwede05 has done on a printer's display is a lot harder than my own pathetic 3dsmax rotated mp4-files, even if the latter looks more impressive - so I vote for randomSwede05. The categories are just there to encourage specific forms of working with the digital material, not to provide exact delimitations of what is legal or not.
Trying to enforce too narrow rules will end in tears or rather: it will end in the party organizers ignoring it, since we cant lure people to Denmark in october with the promise of "maybe one entry, but it follows the rules" - I *can* lure people with "lots of cool entries, yeah some of them might not be exactly the same platform, but we'll put that on the slides, and if you dont know what the words mean, just vote for the one you liked the best".
The best solution (for party organizers, not for coders, I know nothing about that) is to let people judge for themselves within a broad framework - I *know* that what randomSwede05 has done on a printer's display is a lot harder than my own pathetic 3dsmax rotated mp4-files, even if the latter looks more impressive - so I vote for randomSwede05. The categories are just there to encourage specific forms of working with the digital material, not to provide exact delimitations of what is legal or not.
Trying to enforce too narrow rules will end in tears or rather: it will end in the party organizers ignoring it, since we cant lure people to Denmark in october with the promise of "maybe one entry, but it follows the rules" - I *can* lure people with "lots of cool entries, yeah some of them might not be exactly the same platform, but we'll put that on the slides, and if you dont know what the words mean, just vote for the one you liked the best".
and as an addendum I always vote for the one i like the best, especially if she is female and norwegian.
finally.
Why is bittin stealing my job?
The 4k scene survived to bigger difficulties than a missing dll. people can use OpenGL. In DX, somebody will develop the binary shader opcode compressor or do something completely different and unexpected. Who said this was easy. I vote for 1+4.
What about XNA? Or SDL?
SDL was never bundled out of the box in any Windows, nor found on Windows Update, nor in any official MS installation package, so it's out of question.