pouët.net

With any disregard to the cultural aspects, going by the numbers ferris achieved I'd say its certainly possible to ship 64k intros with spir-v, considering that dxil is being superseded by spir-v soon I think the inclusion of dxcompiler.dll just doesn't make any sense, as it'd only be relevant/useful for a comparatively short time period. As to d3dcore... sooner rather than later windows 11 will be the compo (and general mainstream) platform making this a moot point as well.

KeyJ: agreed, but you must admit that calling option to include shader compiler DLL a lame shortcut is a bit unfair, especially considering everyone and their mom so far was using external shader compiler DLL that just happened to be in a stock install. Not to mention those pre-stocked shader compilers tend to break some shaders from driver to driver updates, so including them could potentially even improve the longevity of the intro.

Again, IMHO it's all what you define as a platform. Why only Microsoft has to decide what is "the platform" ?

because you want your prods to be distributed and easily viewed

tomkh: I think the platform discussion is quite off-topic here. We discuss, under the assumption that we accept "a clean {windows or ubuntu 25.04} installation" as the platform for pc64k intros, wheter or not it is acceptable to install additional dlls on the compo machine to allow an additional mechanism for interfacing the graphics card (additionally to the >=3 existing different mechanisms that don't require additional dlls).

how sensible, fair, random or far up Microsoft's arse the choice of platform might be is then irrelevant IMO. Yes, this could be solved by choosing a different platform. But the much simpler solution is not to include additional dlls, right?

The people you're trying to "reach" won't even bother downloading anything but just watch the fucking youtube video and move on.

The PC scene kinda agreed on "GPUs are cool", something like 30+ years ago, the way we interface with them is through their drivers, the drivers implement various APIs, those APIs specified text based shader code input to allow vendors to generate compatible machine code for the GPU, the new APIs(i.e. DX12 and Vulkan) went lower level (on all fronts) and now want instructions rather than human readable code, you know all that, so if you want dispute the use of GPUs through their drivers you're a bit late to the game I'd say. I don't see how you can imply (with a straight face anyways) that it's basically arbitrary coincidence that a stock system install includes a GPU driver. Finally I can only second NR4 here in that I too would prefer to stay at the topic at hand rather than make this a "what is a platform" discussion, go make a new thread about it where we can discuss the inclusion of the jre, chrome, python, unity and demoeffects.dll if you want.

not true, it was all binary compiled up to a certain point, probably like 2008 :)

Personally, like everyone else, I'm all for fair and clear rules that everyone agrees on.

The other problem is those rules must stay somehow consistent over time, so you are able to compare intros with each other. Your intro, may, for example, be compared to Elevated 4k that is number one on charts and is, as smash also pointed out, cheating (his words) a bit, by using minified shader code and external compiler.

It's not hard to imagine than soon enough DX11 will be discontinued altogether. Someone may figure out how to compress SPIR-V to the level of HLSL/GLSL, but so far it is still 2x bigger. That would make Elevated into 8k category.

I understand that there are valid reasons Microsoft is focusing on support for low level IR. So yes, in this sense, if you use DX12, you should probably stick to "standard" DX12. But it's really becoming different platform at this point. And I can understand why including shader compiler DLL could be a reasonable compromise here.

What I don't understand are voices that this is a "lame shortcut" - it's pretty far from it, it's just a desperate attempt to bring some consistency into size-coding chaos. But well, you might be all correct that it's not really a good solution. Still, the fundamental problem is different IMHO we let ourselves loose in general over years...like using external text to speech libraries is allowed...come on!

Precompile all the shaders.
Do things differently.
Generate DXIL at run-time.
Cheat.
Even make it a 96k, 128k/256kb compo, would make things more interesting anyways, imho :)

What are some actual reasons why someone might prefer DX12 over Vulkan for a 64k intro? Does it give access to more hardware features?

I haven't tested this yet but apparently it should be possible to mix dxbc style shaders with dxil (spirv in the future) in dx12 which would mean you'd only need to supply spirv for the more advanced shaders. Not sure if this is possible with vulkan since glcompileshader doesn't give you spirv and vulkan won't accept dxbc. There's probably a big BUT somewhere in there but at the very least worth a look.

An honest question from someone who's not very well versed in this: How is this different from intros that required D3DX9_??.dll back in the day, which wasn't seen as a big deal as far as I remember? Or requiring a particular thing (SDL or whatever) for Linux productions?

I'm not deluded enough to think that generally political problems have technical solutions; however, this is certainly one such case.

As some others have noted I looked into this a bit a few years ago and got to just over 2x for compressed SPIR-V size, and that was in a week or so of putzing on it in my in-laws' basement over Christmas. <=1.5x or even better feels absolutely possible with the same/similar approach, just a bit more work. And that's just filtering SPIR-V so that it could slot into basically any toolchain - it's not even mentioning the fact that this was on a corpus made of compiled GLSL shaders from an already-made intro; these were not at all optimized to generate "optimal" SPIR-V for such a pipeline. And with even more effort and creativity (again as others have mentioned) a compiler/generator approach would surely get that down even more, perhaps even lower than glsl, since the data format can be designed from the ground-up for better compressibility.

And all of that said, you don't actually need any of this - even with 5-6x shader size (which is what you'd get just dumping the raw SPIR-V in your intro), a quite good 64k could easily be made showing off the latest hardware features/temporal accumulation/surfel GI/whatever your heart desires. Because face it - whether or not you have a shader compiler only solves a relatively straightforward technical issue. It's not like once you have that the intro just makes itself. You still have to draw the rest of the fucking owl!

And that's why the rule change doesn't really make any sense to me. It works around a perfectly solvable technical issue which just about any sufficiently motivated person with just a bit of free time (probably not me at this point, but I'd be happy to share code/squishy hack builds/etc with anyone who asks and wants to take what I did further, or just wants to chat about it, because it's a fun problem) could absolutely make a free tool for which would solve the problem for everybody, and then we're still in the same place we started: the intro has to be made. :)

And on that note: I don't understand the animosity towards folks who say "64k should be hard" etc - they're not being negative nancies. Remember when challenges used to be fun? Remember why we started doing these intros and why we like them in the first place? :)

There's a lot of opportunity to creatively approach some really fun problems here, and I'm stoked to see who will pick up the torch next :)

Also, I forgot to mention: this is the only intro I'm aware of that's even attempted to use vk raytracing (quite early on too, props provod!). And it dumped raw SPIR-V into the binary. And it used UPX, since the extensions required 64-bit drivers. Which led me to finally get my ass in gear and make squishy 64-bit. Like, guys, we're so close here, someone just has to jump in and take all the glory and make this entire thread uselesss :)

What ferris and iq said.

Preacher: this is worse, as d3dx9 had a very standard end user runtine installer that a lot games etc used as well. Feels a lot more "updating windows" than manually dropping some exotic dll into you "64k" dir.

I agree that spir-v compression should be feasible for 64k. Also, in dx12, you could use hlsl and shadercompiler.dll for most of your shaders, and then only spir-v when you need SM6 features. Not sure how much code the spir-v transforms themselves are... ferris?

HOWEVER... why do we even need to discuss this when dxcompiler (and other stuff) IS included in an updated windows 11? (and probably even 10, which Revision is weirdly hanging on to)


Not hard to be version independent by searching in the parent path - though maybe not for 5 years, but then just be honest about your dependencies in the readme.

(and support reading the dll from program dir as well)

ha, a sudden plot twist - I love this thread!



...and a pre-installed browser is now part of the platform too! :)

hands off matt or i'll drown you in your own incompetence myself ;)

I find this thread interesting. It reads to me that the new Revision 64K platform specification mean that advanced GPU features cannot be lit up within 64KB today. I have just watched 'Kill Your TV Jim Moirs Weird World of Video Art'. One segment includes George Barber in the 80's who describes 'scratch video':



This exposes a bias for me. I think demo narrative has been undervalued to the detriment of the craft. Microsoft ultimately define the platform and it is inconceivable that they would be making decisions to encourage demo narrative. However, I am happy the consequences seem to be playing out this way. I would suggest there are a couple of paths forward that will keep everyone happy:

* Submit your demo into wild or >64KB, pack your compiler libraries in with the exe, or pack a video with a built in codec. I'm sure the audience you wish to attract will appreciate your technical endeavor.

* Orientate your creative work around the party constraints of 64KB. I'm sure the audience you wish to attract will appreciate your endeavor.

Even if so far my experience with this stuff is limited to doing silly stuff with shadertoy and i won't be submitting any PC 64k to a compo anytime soon... i agree with everything manx said.

If filesize is a problem, then make a demo. Silly enough those are non restricted now. (And obviously someone should make a 4k that uses those dlls anyway - should be easy enough to find them on the compo box)