Yet Another Reason Shaders are more than just COOL eyecandy!

#1 Not sure what your point is. Looks like eyecandy to me. What role do the shaders play that is not eyecandy?

Note: I'm going off the pics. The application does nothing but immediatly crash for me.

#2 Alright.

1. It was pretty.
2. Don't use Alt-F4 to quite, it crashed my session :P
3. If you don't read the readme.txt, it says it has high system req. I noticed. :D

4. Jarrod, what's the shaders doing other than eyecandy in this demo?

#3 Some serious compression and nice use of textures etc. If they did this in 96k then just imagine what they could do in 128k

This type of programming reminds me of the old 64 days when miracles were achieved in 64k of space.

Full Kudos to theprodukkt team

#4 Mmm, guess that it only weights in on 96Kb ?!?!

#5 There are no textures to compress, read what this actually is, it is only code

#6 Oh, so the point is that without shaders this would not have been possible? Cool!

#7 Jarrod, no where is it stated that shaders were used for this. Small demos like this have been written, using no textures, long before shaders existed. Basically the art is programmaticly created.

#8 Actually John is correct.

Here is a cut&paste from their technical FAQ too.

Quote:
- We do .not. have some kind of magical data compression machine that is able to squeeze
hundreds of megabytes of mesh/texture and sound data into 96k. We merely store the
individual steps employed by the artists to produce their textures and meshes, in a very
compact way. This allows us to get .much. higher data density than is achievable with
normal data compression techniques, at some expense in artistic freedom and loading times.
- .kkrieger is not written in 100% assembler/machine language. Not even nearly. Like the
vast majority of game projects being developed today, .kkrieger was mostly written in
C++, with some tiny bits of assembler where it is actually advantageous (notably, there
are a lot of MMX optimisations in the texture generator).
- A kilobyte is, historically, defined to be 1024 (2^10) bytes, not 1000. Thus .kkrieger is
a game in 96k even though it's actually 98304 bytes.
- The concept of the texture/mesh generators was developed by fiver2. We do .not. want to
claim that the techniques we used to develop .kkrieger are new inventions. It's rather a
selection of useful operations and their parameters to optimise the results.

#9 Actually you both are incorrect! Read more type less :-)

Quote:3. system requirements
----------------------

.kkrieger requires a relatively high-end machine to run properly. To be
precise:

- A 1.5GHz Pentium3/Athlon or faster.
- 512MB of RAM (or more)
- A Geforce4Ti (or higher) or ATI Radeon8500 (or higher) graphics card
supporting pixel shaders 1.3, preferably with 128MB or more of VRAM.
- Some kind of sound hardware
- DirectX 9.0b

I assume they are using the hardware pipeline at some point since they specifically states you need Pixel Shader 1.3 support in hardware in the readme.txt and it will not run on anything that does not support Pixel Shaders from what I have tried. The DirectX 9.0 requirement is a good indication of what they are doing also.

#10 Jarrod thats a huge assumption. Just because it uses shaders doesn't mean its using them to do what you say. They could very well be simply using them for eyecandy. Though there is really no way to say which is the correct assumption.

#11 The fact that they cite longer loading times as a trade-off is a pretty strong argument that the texture and mesh generation is being done once in software.

Heck, just watch that memory usage grow during the demo startup. It's obviously not being done per frame, so it would be silly to use the GPU.

#12 Well, it's still pretty cool that its that small.

#13 Err that's one of the coolest things i've ever seen.

Why is there even an arguement about the shaders? You simply can't do most of the effects they create without them (unless you're 100% software, then these people are simply gods).

Awesome.

#14 Yep, very cool.

#15 I was hopeful I'd be able to eek by with my 700mhz/ATI 9500, but to no avail. It just looked really washed-out and would do fly-throughs, but wouldn't let me play.

Pretty neat screenshots. That's amazing.

#16

Quote:Why is there even an arguement about the shaders? You simply can't do most of the effects they create without them (unless you're 100% software, then these people are simply gods).

The discussion (I wouldn't call it an argument.. I have no malice intended), is not whether or not shaders are used, as we know they are. The discussion is whether or not shaders were used to make this as small as it is, or if they were used in the more traditional sense for eyecandy.

Creating a small demo/game is certainly possible without using shaders by programmaticly creating all the art. This is how most "mini" demos are created and have been created since before programmable GPUs, but we have no way of knowing if that is how this one was or not.

#17 Very nice game and I found the loading times to not be slow, but much like most games, very nice :-).

And I think that shaders were used as eyecandy. And nicely done at that!

#18 I find thing kind of thing marginally interesting (old demo coder in me) but utterly pointless (old demo coder who's worked at a game company with demo coders and who knows how useless thier code generally is) :)

nice exercise, but I dont think it shows off shaders any..

BTW: a geforce 4 isnt pixel shader 1.3 capable is it? I've got one and it ran, but I didnt think the 4 had pixel shader beyond 1.0

#19 I'm running a GF4 too. The demo ran but at like 2 fps.

#20 Ran pretty smooth for me, though it would hitch on room transitions.