Live data from Hacker News

Source code for 4kb demoscene production “Elevated” released

files.scene.org

21–30 of 154 posts

Re: Source code for 4kb demoscene production “Elevated” released

#21

Earlier quoted context omitted.

>Seems like it probably offloads most of the work on GPU It does just about everything on the GPU. All the CPU does is repeatedly render two triangles and play music: https://news.ycombinator.com/item?id=8070879 Here it has been adapted to WebGL: https://www.shadertoy.com/view/MdX3Rr Edit: I'm wrong about the two triangles. From the .nfo-file: for those wondering, this a (too) low density flat mesh displaced with a p…

Thanks for detailed response. I figured it mostly did GPU stuff. So, real computing necessary here is a massively-parallel chip with generic and custom hardware with a bunch of memory plus a regular core using 4KB on other end. I think a more interesting challenge would be to force use of a subset of GPU functions or memory plus tiny memory on CPU side. I don't follow demoscene close enough to know if they subset GPU…

You seem to think that GPU programming is somehow easy. You should try it and see what you think.

Yes, there is massive amount of power available but it's not easy to use effectively. You need a different mental model how things work, there's very little shared state and all the algorithms used have to match the model of computation.

Using the GPU almost exclusively, generating everything procedurally is a massive accomplishment and much more difficult than "normal" CPU+GPU programming or using just the CPU.

I do not share your view that this would be somehow less impressive because it uses the GPU.

Re: Source code for 4kb demoscene production “Elevated” released

#22

Earlier quoted context omitted.

>Seems like it probably offloads most of the work on GPU It does just about everything on the GPU. All the CPU does is repeatedly render two triangles and play music: https://news.ycombinator.com/item?id=8070879 Here it has been adapted to WebGL: https://www.shadertoy.com/view/MdX3Rr Edit: I'm wrong about the two triangles. From the .nfo-file: for those wondering, this a (too) low density flat mesh displaced with a p…

Thanks for detailed response. I figured it mostly did GPU stuff. So, real computing necessary here is a massively-parallel chip with generic and custom hardware with a bunch of memory plus a regular core using 4KB on other end. I think a more interesting challenge would be to force use of a subset of GPU functions or memory plus tiny memory on CPU side. I don't follow demoscene close enough to know if they subset GPU…

[deleted]

Re: Source code for 4kb demoscene production “Elevated” released

#23
post #20

For anyone interested/thinks this stuff is cool, the author of Elevated has made a website for experimenting with real time pixel shaders in WebGL: https://www.shadertoy.com/ Some pretty incredible things have been done there.

A friend of mine also has this project, http://shaderfrog.com/

Let's you experiment with and compose different shaders.

Re: Source code for 4kb demoscene production “Elevated” released

#24

Earlier quoted context omitted.

I figured that. It's just that almost everythings done on the GPU for a rendering demo. That's really pushing people. ;)

The wink face makes it seem like you think this is easy because using a GPU to execute the program is allowed. No? Edit: just read your other comment about real challenges in the C64 subset of the demoscene. That's like "You set a record in a 1600m race? For a real challenge, set a record in a marathon." It's just arbitrarily moving the totally legitimate goalposts to a different challenge because you prefer it.

Response to edit: more like they couldn't pull it off so they asked people to buy a better graphics card. That's in their own race. Then I pointed out doing graphics operations, mostly rendering, almost entirely on a graphics card designed for that was barely an accomplishment vs stuff like in C64 demoscene. .kkrieger had me way more impressed due to all the elements involved vs size. So, I suggested subsetting or constraining the graphics card so its hundreds of millions of transistors don't just hand people their victories. Plus allow more creativity.

Re: Source code for 4kb demoscene production “Elevated” released

#25
post #21

Earlier quoted context omitted.

Thanks for detailed response. I figured it mostly did GPU stuff. So, real computing necessary here is a massively-parallel chip with generic and custom hardware with a bunch of memory plus a regular core using 4KB on other end. I think a more interesting challenge would be to force use of a subset of GPU functions or memory plus tiny memory on CPU side. I don't follow demoscene close enough to know if they subset GPU…

You seem to think that GPU programming is somehow easy. You should try it and see what you think. Yes, there is massive amount of power available but it's not easy to use effectively. You need a different mental model how things work, there's very little shared state and all the algorithms used have to match the model of computation. Using the GPU almost exclusively, generating everything procedurally is a massive ac…

I used to do GPU programming. Brief foray into it for game programming plus a then-new field called "GPGPU" pushing its limits. Think I implemented some crypto or physics stuff on one. I've followed some of the recent efforts.

My points of comparison are what they're doing vs what it's designed to do with what vs what other people do with that and other hardware. It looks great with lots of efficiency. I'll give them that. It's just way less impressive to me given they're using a powerful graphics card to mostly do what it's designed to do plus their innovation.

Re: Source code for 4kb demoscene production “Elevated” released

#26

Earlier quoted context omitted.

The wink face makes it seem like you think this is easy because using a GPU to execute the program is allowed. No? Edit: just read your other comment about real challenges in the C64 subset of the demoscene. That's like "You set a record in a 1600m race? For a real challenge, set a record in a marathon." It's just arbitrarily moving the totally legitimate goalposts to a different challenge because you prefer it.

How much harder would it be if software rendered or on a simple GPU from the late 90's? Their executable still 4KB? No?

>How much harder would it be if on a simple GPU from the late 90's

It would be impossible since pixel shaders didn't exist until the 2000's ;-)

As for software rendering: Since a pixel shader is essentially a program executed for every pixel, it's trivially portable to the CPU: Just turn it into a function and call it for every pixel on the screen. Making it fast is another matter altogether though.

Re: Source code for 4kb demoscene production “Elevated” released

#27

Earlier quoted context omitted.

How much harder would it be if software rendered or on a simple GPU from the late 90's? Their executable still 4KB? No?

>How much harder would it be if on a simple GPU from the late 90's It would be impossible since pixel shaders didn't exist until the 2000's ;-) As for software rendering: Since a pixel shader is essentially a program executed for every pixel, it's trivially portable to the CPU: Just turn it into a function and call it for every pixel on the screen. Making it fast is another matter altogether though.

"It would be impossible since pixel shaders didn't exist until the 2000's ;-)"

Lmao. You got me there.

"Just turn it into a function and call it for every pixel on the screen. Making it fast is another matter altogether though."

I was imagining it took up many MB of memory and massive cycles even on a multicore CPU. Suddenly, one faces tough decisions about organization, resolution, primitives, techniques used, algorithms, and so on. Gets really, really hard to make tiny and fast stuff without that GPU doing heavy lifting. :)

Re: Source code for 4kb demoscene production “Elevated” released

#28

Earlier quoted context omitted.

>plus a regular core using 4KB on other end. The .exe is 4K (it has been compressed using Crinkler), not the application's RAM requirements. The game .kkrieger for example is a 96K .exe, but uses several hundred MB of RAM when run. Also, the strict size requirements can interfere with execution speed. From the .nfo again: believe it or not, this was running at 30 fps in a gefoce 7900 at some point, but size optimizat…

Oh yeah, I forgot about that. I wonder what this one's runtime in RAM is. Regarding GPU quote, that's exactly the sort of thing I'm talking about. It's sort of a cheat where a massive amount of resources are used in one place to reduce a tiny amount in another. An impressive optimization requires little to no extra resources in B when optimizing A. There's some types that straight-up can't seem to have that tradeoff.…

>Regarding GPU quote, that's exactly the sort of thing I'm talking about. It's sort of a cheat where a massive amount of resources are used in one place to reduce a tiny amount in another.

Since the demo was originally entered in the 4K competition at the Breakpoint 2009 demo party, it had to run on the computer designated to run the competition's entries. So it's not like it could require an arbitrarily powerful GPU.

Although the compo computer was pretty beefy for the time: https://breakpoint.untergrund.net/2009/compos_pc.php

Re: Source code for 4kb demoscene production “Elevated” released

#29
post #2

Release info: http://www.pouet.net/prod.php?which=52938 Binary: https://files.scene.org/view/parties/2009/breakpoint09/in4k/... Video: https://www.youtube.com/watch?v=jB0vBmiTr6o Everything you see and hear is procedurally generated by the 4096 byte executable, in real time. It still blows my mind 7 years after release...

[deleted]

Re: Source code for 4kb demoscene production “Elevated” released

#30

Earlier quoted context omitted.

Oh yeah, I forgot about that. I wonder what this one's runtime in RAM is. Regarding GPU quote, that's exactly the sort of thing I'm talking about. It's sort of a cheat where a massive amount of resources are used in one place to reduce a tiny amount in another. An impressive optimization requires little to no extra resources in B when optimizing A. There's some types that straight-up can't seem to have that tradeoff.…

>Regarding GPU quote, that's exactly the sort of thing I'm talking about. It's sort of a cheat where a massive amount of resources are used in one place to reduce a tiny amount in another. Since the demo was originally entered in the 4K competition at the Breakpoint 2009 demo party, it had to run on the computer designated to run the competition's entries. So it's not like it could require an arbitrarily powerful GPU…

Fair enough. The spec requirements I'm mentioning would apply to people setting competition requirements more than the authors. The authors should of course work within the constraints for any particular competition. They can still try my challenge on the side.

" Intel Core2Quad at 2.66GHz, 2GB of RAM, with a NVidia GeForce 295 GTX with 2x896MB of VRAM. "

Double CPU and more GPU than what I'm writing this on but half the RAM. Beefy indeed. .exe size is still impressive and all given what they're doing.

Post reply on HN