Hacker News Reader

Comment by adamnemecek | Hacker News Reader

The 4kb restriction isn't there to make it run on weak hw, it's there to push people.

However it does irritate me that it's pregenerating the entire scene in memory. Being allowed to use 300MB of RAM doesn't strike me as very limiting.

You wanted optimized code size and optimized performance?

I mean, sure, but think about how big 4KB is, the tricks that are being used to create the scenes are crazy hacks using default Windows sound files and literally anything the executable can reference on the cheap.

Procedural content generation is really expensive (in general), but that's the beauty of it. You find a way to abstract the content into an algorithm, and then you can reduce the size of the assets, but you pretty much always need to pay the price somewhere.

But hey, I understand the sentiment, I wish Slack didn't consume 2 GB of RAM on my machine.

"Being allowed to use 300MB of RAM doesn't strike me as very limiting."

BOOM! I knew it was going to be huge. That's a beefy GPU + 300MB in RAM + pregenerating. I'd have... made sacrifices to have that even in the Half-Life 1 days. :)

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.

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.

Nitpicking: in the offline rendering world RenderMan had shaders ca. 1990[1], and graphics hackers got around to compiling those for research GPUs in the 90s too[2]. (Hardware had programmability equivalent to current shaders early as well [3], but no compilers for fancy shading languages)

[1] https://people.csail.mit.edu/ericchan/bib/pdf/p289-hanrahan.... [2] http://www.cs.unc.edu/~olano/papers/pxflshading.pdf [3] http://www.cs.unc.edu/~pxfl/papers/high-speed_rendering.pdf

That's some neat stuff. Especially PixelFlow. It had some clever, architectural decisions in terms of memory and computing primitives. Such schemes are already re-appearing in deep learning chips with old work like this maybe having some ideas waiting to be re-discovered.

"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. :)

A soft renderer wouldn't fit in 4096 bytes, too. The overwhelming preference of the demoscene when doing PC filesize compos is to lean on OS provisions in order to free up space for more algorithms. Hence you have demos that use files in C:\Windows as source data. Likewise, you have demos for older computers that require aftermarket RAM upgrades and employ preprocessing techniques that require modern computing resources. In unrestricted compos modern game engines get employed these days, too, and while many of those entries suffer the downside of having a low entry bar, good work has been made too.

Pointing at the GPU as a particular cheat or a make-easy button is not relevant to the conversation, in this light. Having a Gravis Ultrasound was also a cheat back in the day ;) It's all fairly arbitrary stuff, and in the end, the point is to present something cool running on the hardware and within the nominal restrictions, even if you get tricky to do so.

"It's all fairly arbitrary stuff, and in the end, the point is to present something cool running on the hardware and within the nominal restrictions, even if you get tricky to do so."

Another good, detailed perspective on it. Appreciate it. I'll especially agree with the part I quoted. :)

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.

Reply on news.ycombinator.com